View mode: basic / threaded / horizontal-split · Log in · Help
January 15, 2013
Re: Exceptional coding style
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
Re: Exceptional coding style
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
Re: Exceptional coding style
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
Re: Exceptional coding style
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
Re: Exceptional coding style
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
Re: Exceptional coding style
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
Re: Exceptional coding style
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
Re: Exceptional coding style
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
Re: Exceptional coding style
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
Re: Exceptional coding style
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
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home