On 2013-11-19 20:03, John Colvin wrote:

> Doesn't look *that* sparse to me... I think the 8-space indentation give
> a false perspective. E.g. this is actually 1 line longer, but looks denser:

I'm using one tab as indentation. It's Github formatting it like that.

-- 
/Jacob Carlborg

On 2013-11-19 18:11, Jouko Koski wrote:

> If the "user level" validation fails, shall we throw or assert or...?

Throw.

-- 
/Jacob Carlborg

On 11/19/2013 12:19 PM, Jacob Carlborg wrote:
> On 2013-11-19 20:03, John Colvin wrote:
>
>> Doesn't look *that* sparse to me... I think the 8-space indentation give
>> a false perspective. E.g. this is actually 1 line longer, but looks denser:
>
> I'm using one tab as indentation. It's Github formatting it like that.

I've abandoned using tabs as every text rendering engine interprets them differently.

On 11/19/13 12:17 PM, Jacob Carlborg wrote:
> On 2013-11-19 19:29, Andrei Alexandrescu wrote:
>
>> That's not an expression, it's a statement - more precisely an
>> expression statement. (The semicolon makes it so.) By the rules you
>> incorrectly stated, there should be an empty line after it.
>
> I'm sorry for not know every minor detail of the language.

It's not a minor detail. Besides, people took time to explain this to you, and the right response is to integrate that information, not to demean it.

>> I'll allow myself a piece of advice - the density of e.g.
>> https://github.com/jacob-carlborg/dstep/blob/master/dstep/translator/Translator.d#L251
>>
>> is low enough to make it career limiting. You'd do good to change your
>> style.
>
> Are you serious? Anyone caring about that doesn't know what he/she is
> doing.

That's exactly my point. The matter of fact is, in a setting where people are paid to write code, this kind of minor issue would be settled around the first week since hiring. At Facebook for example you'd be submitting a phabricator diff (loosely equivalent to a github pull request) and our linter will point out we use two spaces for indentation instead of tabs, and 80 columns. Then a couple of peers would point out that code is about twice as sparse vertically than it should. You'd fix these issues for good and that would be that. This has happened quite a few times. If, on the other hand, you chose to make a big deal out of it, that would be a cultural mismatch that to my knowledge would be unprecedented.


Andrei

On Tuesday, 19 November 2013 at 21:21:30 UTC, Andrei Alexandrescu wrote:
> On 11/19/13 12:17 PM, Jacob Carlborg wrote:
>> On 2013-11-19 19:29, Andrei Alexandrescu wrote:
>>
>>> That's not an expression, it's a statement - more precisely an
>>> expression statement. (The semicolon makes it so.) By the rules you
>>> incorrectly stated, there should be an empty line after it.
>>
>> I'm sorry for not know every minor detail of the language.
>
> It's not a minor detail. Besides, people took time to explain this to you, and the right response is to integrate that information, not to demean it.
>
>>> I'll allow myself a piece of advice - the density of e.g.
>>> https://github.com/jacob-carlborg/dstep/blob/master/dstep/translator/Translator.d#L251
>>>
>>> is low enough to make it career limiting. You'd do good to change your
>>> style.
>>
>> Are you serious? Anyone caring about that doesn't know what he/she is
>> doing.
>
> That's exactly my point. The matter of fact is, in a setting where people are paid to write code, this kind of minor issue would be settled around the first week since hiring. At Facebook for example you'd be submitting a phabricator diff (loosely equivalent to a github pull request) and our linter will point out we use two spaces for indentation instead of tabs, and 80 columns. Then a couple of peers would point out that code is about twice as sparse vertically than it should. You'd fix these issues for good and that would be that. This has happened quite a few times. If, on the other hand, you chose to make a big deal out of it, that would be a cultural mismatch that to my knowledge would be unprecedented.
>
>
> Andrei

Man, I thought these debates died out long ago. All that matters in style is readability and consistency.

Looking at that code linked above::

1. Is the code formatting consistent? Yes
2. Is the code formatting consistent within the repo? Yes
3. Is the code formatting easily read by a programmer? Yes

Whether you, I, or anyone else like with the style is irrelevant. Personally I'm not a fan, but that doesn't make the author a bad programmer, nor does it make me right. It simply means:

a) Jacob and I prefer different formatting styles and
b) I need to adapt if I'm to work on dstep.

Now if dstep was written at Facebook then OK, the code would need reformatting because it violates point 2. above.

As for Phobos code, insist on tighter style guidelines. No one will care as long as it is consistent and readable. Any programmer worth anything will just adhere to it happily. Those that don't want to are not going to have much to contribute, they're more worried about their personal style than advancing Phobos and D with great code.

Cheers.

On 11/19/2013 04:21 PM, Andrei Alexandrescu wrote:
> On 11/19/13 12:17 PM, Jacob Carlborg wrote:
>> On 2013-11-19 19:29, Andrei Alexandrescu wrote:
>>
>>> That's not an expression, it's a statement - more precisely an
>>> expression statement. (The semicolon makes it so.) By the rules you
>>> incorrectly stated, there should be an empty line after it.
>>
>> I'm sorry for not know every minor detail of the language.
>
> It's not a minor detail. Besides, people took time to explain this to
> you, and the right response is to integrate that information, not to
> demean it.
>
>>> I'll allow myself a piece of advice - the density of e.g.
>>> https://github.com/jacob-carlborg/dstep/blob/master/dstep/translator/Translator.d#L251
>>>
>>>
>>> is low enough to make it career limiting. You'd do good to change your
>>> style.
>>
>> Are you serious? Anyone caring about that doesn't know what he/she is
>> doing.
>
> That's exactly my point. The matter of fact is, in a setting where
> people are paid to write code, this kind of minor issue would be settled
> around the first week since hiring. At Facebook for example you'd be
> submitting a phabricator diff (loosely equivalent to a github pull
> request) and our linter will point out we use two spaces for indentation
> instead of tabs, and 80 columns. Then a couple of peers would point out
> that code is about twice as sparse vertically than it should. You'd fix
> these issues for good and that would be that. This has happened quite a
> few times. If, on the other hand, you chose to make a big deal out of
> it, that would be a cultural mismatch that to my knowledge would be
> unprecedented.
>
>
> Andrei
>

This is great stuff for every developer to learn, but can someone please create (or start creating) a code formatting tool for D?
I guess it's even worth putting some bounties on it, if that helps.

On Wednesday, 20 November 2013 at 01:30:18 UTC, John J wrote:
> On 11/19/2013 04:21 PM, Andrei Alexandrescu wrote:
>> On 11/19/13 12:17 PM, Jacob Carlborg wrote:
>>> On 2013-11-19 19:29, Andrei Alexandrescu wrote:
>>>
>>>> That's not an expression, it's a statement - more precisely an
>>>> expression statement. (The semicolon makes it so.) By the rules you
>>>> incorrectly stated, there should be an empty line after it.
>>>
>>> I'm sorry for not know every minor detail of the language.
>>
>> It's not a minor detail. Besides, people took time to explain this to
>> you, and the right response is to integrate that information, not to
>> demean it.
>>
>>>> I'll allow myself a piece of advice - the density of e.g.
>>>> https://github.com/jacob-carlborg/dstep/blob/master/dstep/translator/Translator.d#L251
>>>>
>>>>
>>>> is low enough to make it career limiting. You'd do good to change your
>>>> style.
>>>
>>> Are you serious? Anyone caring about that doesn't know what he/she is
>>> doing.
>>
>> That's exactly my point. The matter of fact is, in a setting where
>> people are paid to write code, this kind of minor issue would be settled
>> around the first week since hiring. At Facebook for example you'd be
>> submitting a phabricator diff (loosely equivalent to a github pull
>> request) and our linter will point out we use two spaces for indentation
>> instead of tabs, and 80 columns. Then a couple of peers would point out
>> that code is about twice as sparse vertically than it should. You'd fix
>> these issues for good and that would be that. This has happened quite a
>> few times. If, on the other hand, you chose to make a big deal out of
>> it, that would be a cultural mismatch that to my knowledge would be
>> unprecedented.
>>
>>
>> Andrei
>>
>
> This is great stuff for every developer to learn, but can someone please create (or start creating) a code formatting tool for D?
> I guess it's even worth putting some bounties on it, if that helps.

I find astyle works very well for D.

http://astyle.sourceforge.net/

On Tue, Nov 19, 2013 at 08:30:18PM -0500, John J wrote:
> On 11/19/2013 04:21 PM, Andrei Alexandrescu wrote:
[...]
> >That's exactly my point. The matter of fact is, in a setting where people are paid to write code, this kind of minor issue would be settled around the first week since hiring. At Facebook for example you'd be submitting a phabricator diff (loosely equivalent to a github pull request) and our linter will point out we use two spaces for indentation instead of tabs, and 80 columns. Then a couple of peers would point out that code is about twice as sparse vertically than it should. You'd fix these issues for good and that would be that. This has happened quite a few times. If, on the other hand, you chose to make a big deal out of it, that would be a cultural mismatch that to my knowledge would be unprecedented.
[...]
> This is great stuff for every developer to learn, but can someone
> please create (or start creating) a code formatting tool for D?
> I guess it's even worth putting some bounties on it, if that helps.

The main holdup is the lack of a ready-made, official D lexer/parser. Nobody wants to manually maintain their own version of the D lexer/parser given how fast the language is still developing (plus, it sucks to have to keep fixing lexing/parsing bugs just because DMD's lexer/parser doesn't quite work the way you thought it would).

Once we have this in place, I'm quite confident that a lot of nice D tools would spring up. Pretty-printing is, after all, one of the simplest uses of lexers/parsers.


T

-- 
One reason that few people are aware there are programs running the internet is that they never crash in any significant way: the free software underlying the internet is reliable to the point of invisibility. -- Glyn Moody, from the article "Giving it all away"

"Jacob Carlborg"  wrote:
> On 2013-11-19 18:11, Jouko Koski wrote:
>
>> If the "user level" validation fails, shall we throw or assert or...?
>
> Throw.

Ok. What if the "user" is writing a library code which calls other system utilities? If the validation fails, is the answer now assert?

I don't have a definite answer. However, I tend to follow the practice that all public API should do validation and throw on failures. I use assert for catching my own mistakes in more or less internal stuff.

Usually I don't find separate validation API functions very practical. One can forget or ignore to do validation, just like one can fail to check errno after a call. Of course, validation is necessary and exceptions can assert (sic!) this. It might be more of a personal preference, but often I catch exceptions only for error reporting purposes. Exception is an indication of an unexpected condition in the program. The solution is to fix the program to be prepared for the condition, not trying to fix the condition afterwards as the exception has already fired. Not all APIs support this approach.

-- 
Jouko

On 2013-11-19 22:21, Andrei Alexandrescu wrote:

> It's not a minor detail. Besides, people took time to explain this to
> you, and the right response is to integrate that information, not to
> demean it.

I think so. I've not magically become a better programmer just because I know this information. I can also tell you that a lot of programmers have no idea what's the difference between an expression and a statement. Many have not even header of those words.

The first person that said that an expression ending with a semicolon is a statement was David, and my reply was "Ok, I didn't know that.". What's so demeaning about that?

> That's exactly my point. The matter of fact is, in a setting where
> people are paid to write code, this kind of minor issue would be settled
> around the first week since hiring. At Facebook for example you'd be
> submitting a phabricator diff (loosely equivalent to a github pull
> request) and our linter will point out we use two spaces for indentation
> instead of tabs, and 80 columns. Then a couple of peers would point out
> that code is about twice as sparse vertically than it should. You'd fix
> these issues for good and that would be that. This has happened quite a
> few times. If, on the other hand, you chose to make a big deal out of
> it, that would be a cultural mismatch that to my knowledge would be
> unprecedented.

Don't you think I can adapt to a particular style that a company or project is using?

I can tell you that I would love to have code reviews like you have at Facebook. We have just started using code reviews at my work, it only took me three _years_ to get to that.

I can also say that we have lines with over 400 columns, I hate it. But it's there because no one cared enough.

I think it would be insulting if someone about to hire me can't see through the formatting of my code and base a decision on that. I would have no interest in working for someone like that. I don't even want to know what other strange things that can be hiding in that company behaving like that.

Who said your style is a better one that I should follow.

I should just stop this because it doesn't lead anywhere.

-- 
/Jacob Carlborg