January 15, 2013
On 2013-01-15 08:24, Tavi Cacina wrote:
> Am 15.01.2013 01:55, schrieb Stewart Gordon:
>> vec.erase(std::remove(vec.begin(), vec.end(), val), vec.end());
>
> That piece of code is correct.
> http://en.wikipedia.org/wiki/Erase-remove_idiom

All thanks to a terrible naming decision...
It's not remove but move_to_end. Why call it remove?
January 15, 2013
On 2013-01-15 09:29, monarch_dodra wrote:
> I still prefer "writeln" over "writefln". While writefln issafe, you
> can still botch the amount of args, and or flag types, in which case
> writefln will throw. Writeln never throws (due to a code error).

What about the argument that a format string makes translation easier?
January 15, 2013
On Monday, 14 January 2013 at 23:48:14 UTC, bearophile wrote:
>> And extra vertical spaces are like semantic formatting tools for plain text - can group related blocks perfectly and speed up reading.
>
> The idea of not wasting lines doesn't go against the idea of adding blank lines to create code paragraphs. When you are adding a line to divide chunks, you are not wasting vertical space, it's a well used line :-)
>
> Bye,
> bearophile

Well, I would not rant about this if not his actual example in "Spacing" block. This very example of "bad" code has every empty line added right where it fits. And "good" one is a mess that hurts my eyes when I try to concentrate on some distinct parts.
January 15, 2013
On Monday, 14 January 2013 at 23:57:18 UTC, Timon Gehr wrote:
> This generally comes up as an argument in these discussions, but I don't buy it. Not all development is done on a desktop with a huge screen. And even then, there is always something to put on it. What window manager are you using?

Well, I hardly can imagine rationale behind using netbook for serious development aside from being on trip. Even being forced to work in ssh to some legacy shell ( I have that unpleasant experience :( ) usually limits your term width, not height.

I am using Gnome Shell, but working mostly in full-screen undecorated terminal. It is approximately 75 to 85 lines of vertical space in my setup.
January 15, 2013
Well, probably I am playing "good vision nazi" here, as 12 font size seems HUGE to me, far beyond the comfort zone.
January 15, 2013
On Mon, 2013-01-14 at 11:24 -0800, Walter Bright wrote:
> Quite a nice read on the coding style used in Doom.
> 
> http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550

On the other hand I don't like some parts of the style he is putting forward as good.

Go has an extreme position on this, there is one and only one style of code that is acceptable, the one defined in the gofmt program that is used to format all Go code. I happen not to like some parts of it, but I live with the enforced style.

Python is less extreme, in that there are many styles of code allowed, but there is PEP-8 which is "Python style as Guido intended".  This is supported by the pep8 program for enforcing elements of style. I have disagreement with some of the choices, but I live with it, and format my code to PEP-8 except for the line length rule – which is just so 1980s.

C, C++, D, Fortran, Groovy, probably need to learn a lesson from one or other of these.

The issue is that having a single global style standard for a
programming language makes it easier to read code in that language.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


January 15, 2013
On Tuesday, 15 January 2013 at 10:47:19 UTC, mist wrote:
> On Monday, 14 January 2013 at 23:48:14 UTC, bearophile wrote:
>>> And extra vertical spaces are like semantic formatting tools for plain text - can group related blocks perfectly and speed up reading.
>>
>> The idea of not wasting lines doesn't go against the idea of adding blank lines to create code paragraphs. When you are adding a line to divide chunks, you are not wasting vertical space, it's a well used line :-)
>>
>> Bye,
>> bearophile
>
> Well, I would not rant about this if not his actual example in "Spacing" block. This very example of "bad" code has every empty line added right where it fits. And "good" one is a mess that hurts my eyes when I try to concentrate on some distinct parts.

The spacing section is exactly the coding style I use, and omitting the curly braces will rather sooner than later lead to more work. Also, "a function should only do one thing" has proven to work for me. Although there might be a slight performance penalty if you have more function calls, code maintenance is by far easier.

January 15, 2013
On 01/15/13 00:37, bearophile wrote:
> Walter Bright:
> 
>> http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550
> 
> From the article:
> 
>> [Side note: John Carmack has stated that static analysis tools revealed that their common bug was incorrect parameter matching in printf(). I wonder if they've changed to stringstreams in Rage because of this. GCC and clang both find printf() parameter matching errors with -Wall, so you don't need expensive static analysis tools to find these errors.]
> 
> I'd like the D front-end to statically detect wrong parameter matching errors for the write*()/format() functions. (In D I don't use "%s" all the time).

Library territory. There's no need to put this in a D compiler.

Except if you'd like to have 'printf("%.2g", d)' instead of 'printf!"%.2g"(d)'
syntax.
Which could be done via a 'printf(enum string, ...);' overload [1] - still
no need for placing the format string verification logic inside the front end.

artur

[1] 'enum' is a better fit for current D, 'static' would be better if 'static' would be defined saner. For this case the name of the storage class does not really matter.
January 15, 2013
Artur Skawina:

> Library territory. There's no need to put this in a D compiler.

One of the threads about possible ways to allow to implement that in library code:

http://forum.dlang.org/thread/nxhsgwliuwdgidaoudud@forum.dlang.org


> Except if you'd like to have 'printf("%.2g", d)' instead of 'printf!"%.2g"(d)' syntax.

In some cases I don't mind a syntax like 'printf!"%.2g"(d)'. But I'd like D to offer ways to remove/avoid template bloat in most of those cases.

Bye,
bearophile
January 15, 2013
On 2013-58-15 11:01, Russel Winder <russel@winder.org.uk> wrote:

> On Mon, 2013-01-14 at 11:24 -0800, Walter Bright wrote:
>> Quite a nice read on the coding style used in Doom.
>>
>> http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550
>
> On the other hand I don't like some parts of the style he is putting
> forward as good.
>
> Go has an extreme position on this, there is one and only one style of
> code that is acceptable, the one defined in the gofmt program that is
> used to format all Go code. I happen not to like some parts of it, but I
> live with the enforced style.
>
> Python is less extreme, in that there are many styles of code allowed,
> but there is PEP-8 which is "Python style as Guido intended".  This is
> supported by the pep8 program for enforcing elements of style. I have
> disagreement with some of the choices, but I live with it, and format my
> code to PEP-8 except for the line length rule – which is just so 1980s.
>
> C, C++, D, Fortran, Groovy, probably need to learn a lesson from one or
> other of these.
>
> The issue is that having a single global style standard for a
> programming language makes it easier to read code in that language.

I agree a canonical form could be nice. Even so, I am firmly of the
opinion that such should not be forced upon programmers. Prettifiers
certainly can help here.

-- 
Simen