View mode: basic / threaded / horizontal-split · Log in · Help
April 13, 2011
Re: [OT] Spaces/tabs (Was: simple display (from: GUI library for D))
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
April 14, 2011
Re: [OT] Spaces/tabs (Was: simple display (from: GUI library for D))
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
April 14, 2011
Re: [OT] Spaces/tabs (Was: simple display (from: GUI library for D))
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
April 14, 2011
Re: [OT] Spaces/tabs (Was: simple display (from: GUI library for D))
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
June 03, 2011
Re: [OT] Spaces/tabs (Was: simple display (from: GUI library for D))
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
June 03, 2011
Re: [OT] Spaces/tabs (Was: simple display (from: GUI library for D))
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
June 03, 2011
Re: [OT] Spaces/tabs (Was: simple display (from: GUI library for D))
I bet you wrote std.datetime with a call to a single Vim macro.

Just kidding. :P
June 03, 2011
Re: [OT] Spaces/tabs (Was: simple display (from: GUI library for D))
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
June 03, 2011
Re: [OT] Spaces/tabs (Was: simple display (from: GUI library for D))
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.
June 03, 2011
Re: [OT] Spaces/tabs (Was: simple display (from: GUI library for D))
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.
8 9 10 11 12 13
Top | Discussion index | About this forum | D home