On 4/13/11 4:17 PM, "Jérôme M. Berger" wrote:
> Nick Sabalausky wrote:
>> ""J�r�me M. Berger""<jeberger@free.fr>  wrote in message
>> news:io4sng$1p9b$1@digitalmars.com...
>>> Nick Sabalausky wrote:
>>>> ""J?r?me M. Berger""<jeberger@free.fr>  wrote in message
>>>> news:io230l$1ldc$3@digitalmars.com...
>>>>> Well, I have worked in both environments, and I have seen a lot
>>>>> more mess ups with tabs than with spaces... Other than that (and the
>>>>> fact that almost *no* editors are able to do it properly), I would
>>>>> really prefer "tabs for indent, spaces for align".
>>>> I prefer "tabs for indent, tabs for align, spaces for separation", but
>>>> that
>>>> requires elastic tabstops. And at least one of the biggest code-edit
>>>> controls out there (the one I use), Scintilla, doesn't support them :(
>>>>
>>>>
>>> That depends what you mean by "align". I agree that for the
>>> following, elastic tab stops would be best:
>>>
>>> int      a;
>>> SomeType b;
>>>
>>> However, for this, I think that spaces are better:
>>>
>>> doSomething (someLongParameterThatJustifiesBreakingTheLine,
>>>              someOtherLongParameterJustInCase);
>>
>> I guess we disagree on that. Like I said in another branch, I used to do
>> that, but then I found that mixing tabs/spaces before the first
>> non-whitespace on a line is just asking for trouble.
>>
> 	Yes, that is the main reason why I use spaces for indenting...
>
>> I'd rather do it like this (assuming elastic tabstops):
>>
>> doSomething(->someLongParameterThatJustifiesBreakingTheLine,
>> ->             someOtherLongParameterJustInCase);
>>
>> Of course, that does demonstrate that I've never liked putting any
>> whitespace between a function name (or if/while/etc.) and the opening paren.
>> YMMV.
>>
> 	Well, standard (printed) typographic practices put spaces outside
> the parenthesis and none inside. And as opposed to a lot of
> typographic rules, that one is a constant across languages and variants.

Math typography rules also preclude inserting a space between a function's name and the opening brace. That's why I consistently go with no space after the opening paren or before the closing paren. Also, that's why there's no need to make if (condition) and func(args) consistent with regard to space before opening paren. In the first case the paren is pure punctuation; in the latter it is an organic part of the function invocation syntax. So one should never leave a space between function name and opening paren, and decide independently regarding the existence of a space between if/while etc. and the opening paren.


Andrei

On 04/13/2011 11:44 PM, Andrei Alexandrescu wrote:
> On 4/13/11 4:17 PM, "Jérôme M. Berger" wrote:
>> Well, standard (printed) typographic practices put spaces outside
>> the parenthesis and none inside. And as opposed to a lot of
>> typographic rules, that one is a constant across languages and variants.
>
> Math typography rules also preclude inserting a space between a function's name
> and the opening brace. That's why I consistently go with no space after the
> opening paren or before the closing paren. Also, that's why there's no need to
> make if (condition) and func(args) consistent with regard to space before
> opening paren. In the first case the paren is pure punctuation; in the latter
> it is an organic part of the function invocation syntax. So one should never
> leave a space between function name and opening paren, and decide independently
> regarding the existence of a space between if/while etc. and the opening paren.

Agreed.
In the same vein, function definition is not a function call; thus I use to write:

	int square (int n) {
	    return n * n;
	}
	sq = square(3);

Actually, I have never been pleased that func defs (1) look like func calls (2) have an exceptional syntax compared to other definitions. I'd like instead eg:

	square = function (int n) int {
	    return n * n;
	}

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

spir wrote:
> Actually, I have never been pleased that func defs (1) look like func
> calls (2) have an exceptional syntax compared to other definitions. I'd
> like instead eg:
> 
>     square = function (int n) int {
>         return n * n;
>     }
> 
	That is still different from other definitions where the type comes
first. But the following would work too:

function (int n) int square = {
   return n*n;
}

	And both would be easier to parse to boot:) There are actually
languages out there with this kind of syntax.

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

On 04/14/2011 07:58 PM, "Jérôme M. Berger" wrote:
> spir wrote:
>> Actually, I have never been pleased that func defs (1) look like func
>> calls (2) have an exceptional syntax compared to other definitions. I'd
>> like instead eg:
>>
>>      square = function (int n) int {
>>          return n * n;
>>      }
>>
> 	That is still different from other definitions where the type comes
> first.

True. I was firstly evoking the "x = y" form.

>  But the following would work too:
>
> function (int n) int square = {
>     return n*n;
> }
>
> 	And both would be easier to parse to boot:)

Yes, I like your format as well.

>  There are actually
> languages out there with this kind of syntax.

Yop, I know (my example was Lua-like: we are not reinventing the wheel ;-)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On 12/04/2011 20:49, Nick Sabalausky wrote:
>
>> Can we move along now?  This argument was old 30 years ago.  Perhaps we
>> should do VI vs. EMACS while we are at it.
>>
>
> Pico rules them all! ;)
>
>

Vi *and* Emacs suck. Argument settled :P

(yes, that was hyperbolic rhetoric)

-- 
Bruno Medeiros - Software Engineer

On 2011-06-03 05:45, Bruno Medeiros wrote:
> On 12/04/2011 20:49, Nick Sabalausky wrote:
> >> Can we move along now? This argument was old 30 years ago. Perhaps we should do VI vs. EMACS while we are at it.
> > 
> > Pico rules them all! ;)
> 
> Vi *and* Emacs suck. Argument settled :P

Yeah, I got sucked in by vim, and I've never gotten away. ;)

- Jonathan M Davis

I bet you wrote std.datetime with a call to a single Vim macro.

Just kidding. :P

On 2011-06-03 11:01, Andrej Mitrovic wrote:
> I bet you wrote std.datetime with a call to a single Vim macro.
> 
> Just kidding. :P

That sort of talk leads to things like this: http://xkcd.com/378/

- Jonathan M Davis

On 4/10/2011 10:58 PM, Daniel Gibson wrote:
> Am 11.04.2011 07:51, schrieb Jonathan M Davis:
>> Yes. Phobos follows the convention of indenting with spaces and that levels of
>> indentation are 4 spaces. So, anything which goes into Phobos needs to follow
>> this convention.
>>
>> the only way that tabs work is if you use them consistently, which in my
>> experience almost never happens.
>
> How can people mess that up?

In the beginning, God created tabs. Tab stops were 8 spaces. That was engraved in tty and printer hardware, and there was nothing any user could do about it. And it was good, and there was peace in the land.

But then in the 80's satan thought that it would be a good idea to make tabs user settable (soft tabs) in his text editor. Various demons and trolls thought this was a fab idea, and propagated it to every text editor.

Unfortunately, text files have no way to specify the tab size expected by the text. Conventions were proffered, noobs were sacrificed, and hymns sung, but nobody could ever agree on what the tab size should be. Bikeshed wars raged and devastated the land.

Hence, the use of tabs was utterly, totally and perpetually ruined for everyone. And satan laughed at the folly of programmers.

On 4/11/2011 8:31 AM, Adam D. Ruppe wrote:
> Yeah, that's all that matters in the end. "When in Rome..."
>
> But it's trivial to do a find and replace all before submitting so
> really, it's just not a big deal.

Before I check in, I run tolf and detab on the source files.