Linked by Thom Holwerda on Tue 15th Jan 2013 21:24 UTC
General Development "I was really excited to write this article, because it gave me an excuse to really think about what beautiful code is. I still don't think I know, and maybe it's entirely subjective. I do think the two biggest things, for me at least, are stylistic indenting and maximum const-ness. A lot of the stylistic choices are definitely my personal preferences, and I'm sure other programmers will have different opinions. I think the choice of what style to use is up to whoever has to read and write the code, but I certainly think it's something worth thinking about. I would suggest everyone look at the Doom 3 source code because I think it exemplifies beautiful code, as a complete package: from system design down to how to tab space the characters." John Carmack himself replies in the comments.
Order by: Score:
Good article
by WorknMan on Tue 15th Jan 2013 22:33 UTC
WorknMan
Member since:
2005-11-13

This is going to be a post about personal preferences ...

Being the novice programmer that I am, some of it was over my head, but other parts of it I could comprehend.

One thing that struck me is the part about where to put the braces. Personally, braces just look messy to me, so I'd rather use a language without them. IMHO, having a terminating statement like 'END IF' is a lot more elegant than having braces all over the f**king place.

And don't even get me started on semi-colons ;)

Reply Score: 4

RE: Good article
by ebasconp on Tue 15th Jan 2013 23:32 UTC in reply to "Good article"
ebasconp Member since:
2006-05-09

You'll learn to love them; like the most of us ;)

You can start flamewars just because of mentioning where the curly braces should be!!

I actually prefer writing:

int main()
{
}


to

int main() {
}

but, apart of feeling it more natural and making easier to see where a block starts and ends, I do not have any excuse to prefer it over the other one.

Reply Score: 4

RE[2]: Good article
by hashnet on Wed 16th Jan 2013 03:38 UTC in reply to "RE: Good article"
hashnet Member since:
2005-11-15

Not just a matter of aesthetics; it also depends on the tools you use.

With XEmacs, when the cursor is at a closing brace, the line with the matching opening brace is shown in the status bar.
With this setup, it is advantageous to place the opening brace and function definition on the same line for quick reference.

Reply Score: 2

RE[2]: Good article
by lucas_maximus on Wed 16th Jan 2013 07:16 UTC in reply to "RE: Good article"
lucas_maximus Member since:
2009-08-18

I also think it depends on the language you are writing in where you should put it.

e.g.

If it is JavaScript Douglas Crockford recommends the opening brace should be on the first line, because of JavaScript semi-colon insertion mechanism.

Java is the same due to convention. Microsoft recommend you use opening brace on the following line as you do when writing C# and is the visual studio intellisense default.

Personally I somewhat agree with the OP and I have had a gutful of C style syntax.

Reply Score: 2

RE[2]: Good article
by Wafflez on Wed 16th Jan 2013 10:58 UTC in reply to "RE: Good article"
Wafflez Member since:
2011-06-26

Same, Allman style is the best!

Especially when programmers tend to have atleast 1200 pixels of height on their screens (well atleast I hope programmers are smarter than average consumer and don't give in into 16:9 fad just because it's cheaper for Samsung to make 23" 16:9 than 23" 16:10...).

Edited 2013-01-16 11:04 UTC

Reply Score: 1

RE[2]: Good article
by Kochise on Wed 16th Jan 2013 16:40 UTC in reply to "RE: Good article"
Kochise Member since:
2006-03-03

Please, be my guest :

http://www.codeproject.com/script/Articles/MemberArticles.aspx?amid...

Especially check my CSkinProgress and WaterMarker source code : space instead of tab, 2 space indent, hungarian notation, one instruction per line, etc...

Kochise

Reply Score: 2

RE: Good article
by panzi on Tue 15th Jan 2013 23:47 UTC in reply to "Good article"
panzi Member since:
2006-01-22

I think curly braces stand out more from the rest of the code than yet another word.

Reply Score: 2

RE: Good article
by ssokolow on Tue 15th Jan 2013 23:57 UTC in reply to "Good article"
ssokolow Member since:
2010-01-21


One thing that struck me is the part about where to put the braces. Personally, braces just look messy to me, so I'd rather use a language without them. IMHO, having a terminating statement like 'END IF' is a lot more elegant than having braces all over the f**king place.

And don't even get me started on semi-colons ;)


I'll agree with you on the semicolons and I do like Python's indent-based block syntax, but using words rather than curly braces is one of the reasons I've never tried to learn Ruby and refer to it as the bastard child of Java, Perl, and BASIC.

(Though by no means the only reason. The standard library and core language syntax are full of caveats, the Unicode support is inferior to Python's, it's not used much outside of Rails and apps based on it, etc.)

I think curly braces stand out more from the rest of the code than yet another word.


Agreed. The only thing that stands out more is probably the indenting itself.

You'll learn to love them; like the most of us ;)

You can start flamewars just because of mentioning where the curly braces should be!!

I actually prefer writing:

int main()
{
}


to

int main() {
}

but, apart of feeling it more natural and making easier to see where a block starts and ends, I do not have any excuse to prefer it over the other one.


Seeing all that wasted vertical space just drives me nuts. (Partly because it means more scrolling, more time spent repositioning my Vim cursor when scrolling drags it along for the ride, and more time reacquiring my train of thought when scrolling sometimes disrupts it)

...not to mention it doesn't fit as nicely with my Python-originated mental model that an indent level (syntactic block) is generally associated with the first line prior.

In fact, I'm sure that, in some places, I've been guilty of writing slightly less than ideal code using things like the ternary operator (PHP, mostly) and list comprehensions (Python) in order to vertically-compact my code.

Edited 2013-01-15 23:59 UTC

Reply Score: 4

RE[2]: Good article
by kwan_e on Wed 16th Jan 2013 00:07 UTC in reply to "RE: Good article"
kwan_e Member since:
2007-02-18

In fact, I'm sure that, in some places, I've been guilty of writing slightly less than ideal code using things like the ternary operator (PHP, mostly) and list comprehensions (Python) in order to vertically-compact my code.


I personally think list comprehensions are a cool feature and should be used more, not just in Python. It may be harder to figure out what it does, but at a glance, at least you can tell what kind of things are in the list.

Reply Score: 2

RE[3]: Good article
by ssokolow on Wed 16th Jan 2013 06:28 UTC in reply to "RE[2]: Good article"
ssokolow Member since:
2010-01-21

I personally think list comprehensions are a cool feature and should be used more, not just in Python. It may be harder to figure out what it does, but at a glance, at least you can tell what kind of things are in the list.


I normally agree wholeheartedly (one of many reasons why I love using CoffeeScript in place of writing Javascript directly), but even they can be abused.

See, for example, this inefficient one-liner I've used as a disposable snippet for doing 90% of the parsing of simple, un-sectioned, unquoted rcfile-like key=value files in reference-counted implementations of Python:

dict([line.strip().split('=') for line in open(whatever) if line.strip() and not line.lstrip().startswith('#')])

(90% because it still needs an extra step to trim whitespace from the key and value names but I don't remember off-hand how to cram that into the same line.)

Reply Score: 2

RE[2]: Good article
by galvanash on Wed 16th Jan 2013 00:43 UTC in reply to "RE: Good article"
galvanash Member since:
2006-01-25

Yeah... The beauty of indent-controlled blocking in languages like Python and Coffeescript is that it kills multiple birds with one stone:

1. It eliminates a lot of noise.
2. It makes something that everyone does anyway for readability actually mean something.
3. It effectively kills most styling arguments (not all, but most).

Anyway, I'm quite fond of it.

Reply Score: 2

RE[2]: Good article
by moondevil on Wed 16th Jan 2013 10:04 UTC in reply to "RE: Good article"
moondevil Member since:
2005-07-08

And then the nicely formatted code gets thrown away when another team member gets to touch the code.

That is why I just follow what is the project guidelines, regardless how I feel about them.

Reply Score: 3

RE: Good article
by kwan_e on Wed 16th Jan 2013 00:02 UTC in reply to "Good article"
kwan_e Member since:
2007-02-18

IMHO, having a terminating statement like 'END IF' is a lot more elegant than having braces all over the f**king place.


Well, at least it's your "humble opinion"...

Reply Score: 6

RE: Good article
by Laurence on Wed 16th Jan 2013 00:02 UTC in reply to "Good article"
Laurence Member since:
2007-03-26

Having programmed in both, I they both have pros and cons.

The real problems are:
1: badly formatted code,
2: lack of naming conventions,
3: and bad program design

1
--
Badly formatted code will make even the most readable of languages a struggle to follow.

2
--
It doesn't matter how well you format your code, if your function / variable names are badly chosen (eg abbreviated names that mean nothing to anyone but the developer) and there's no clear naming convention, then it can be a tough job understanding what the routine does.

I will also add, overly verbose names are bad too (I have one colleague who uses entire sentences in their function names. While it's helps explain what the function does, it makes code readability more challenging).

3
--
Bad program design is a more subjective topic. Most (if not all) developers roughly agree on indentation; and naming conventions only have to be readable, concise and consistent. Not everyone agrees on the specifics of naming conventions, but as long as those 3 criteria are met, then anyone new to the code can quickly understand the standards applied to that particular project.

However bad program design is about the code design of the code - when to you objects, functions, iteration and so on. Sometimes application performance is paramount, which often means writing clever routines in a manner that isn't ideal for a human reading back. Other times you'll be writing a program which isn't going to tax the processor much, so you can afford to opt for readability over performance (Sometimes you're lucky and the optimised code is also the most readable code).

Then you have people using obscure language features or unpopular features (goto is a great example of that. But thankfully there's very few occasions when a goto is the better method of writing a routine).

And after all that, you have the topic of code separation (eg using MVC's in web development to keep server side code separate from HTML).

----------

At the end of the day, it doesn't really matter whether your language uses English words or braces - a good developer can make their code readable.

But also, a lot of it comes down to practice. If you've never spent any time developing in C-derived languages, then the C syntax will naturally look a mess. But most developers get used to it and even come to love braces (that certainly happened to me).

Reply Score: 3

RE[2]: Good article
by ebasconp on Wed 16th Jan 2013 01:25 UTC in reply to "RE: Good article"
ebasconp Member since:
2006-05-09

I had a computer programming teacher that used to prefer:

a = a + 1;

to

a++;

in the name of readibility!!!

So, "readable code" is a very subjective term and in this case, if my teacher could not read the "++" thing... we have a problem!

Reply Score: 2

RE[3]: Good article
by WorknMan on Wed 16th Jan 2013 02:22 UTC in reply to "RE[2]: Good article"
WorknMan Member since:
2005-11-13

I actually prefer the first way myself, even though I can read the second. In general, I don't mind code that's a little more verbose, if it's easier to read.

Obviously though, there is a tradeoff between readability and verbosity; if you're using 30 lines of code to do something that could be done in 3, you could probably do better. On the other hand, if those 3 lines of code look like modem line noise on a terminal (as many perl scripts seem to end up looking like), I'd rather have the 30 lines ;)

Reply Score: 3

RE[4]: Good article
by Laurence on Wed 16th Jan 2013 09:57 UTC in reply to "RE[3]: Good article"
Laurence Member since:
2007-03-26

On the other hand, if those 3 lines of code look like modem line noise on a terminal (as many perl scripts seem to end up looking like), I'd rather have the 30 lines :p

But again, this is all down to experience. A good Perl developer should be able to read that code easily enough.

Where I draw the line is over-engineered regex:
* they can be completely unreadable - even to many seasoned developers
* and they usually run slower then multiple, more precise, expressions.

A basic example is a 'trim' command. The following will remove spaces from the start and the end of the string:
s/(^\s|\s$)//
However it's actually computationally less efficient then having two separate replaces:
s/^\s//
s/\s$//


So the real issue isn't Perl's syntax, it's that you're either reading bad Perl code, or that you're not familiar enough with Perl to understand it's syntax.

And this is my problem with people who bang on about how bad Perl / C++ / etc is for readability vs Python / VB / etc. Those people are generally inexperienced developers and thus not really qualified to comment. It's a bit like saying simplified Chinese is less readable than English, because I'm an English speaker who's only exposure to Chinese is from friends of that heritage.

Reply Score: 2

RE[5]: Good article
by Brendan on Wed 16th Jan 2013 15:58 UTC in reply to "RE[4]: Good article"
Brendan Member since:
2005-11-16

Hi,

Where I draw the line is over-engineered regex:
* they can be completely unreadable - even to many seasoned developers
* and they usually run slower then multiple, more precise, expressions.


The other problem is adequate error handling.

For me, adequate error handling means telling the user what was wrong with descriptive error messages; like "missing space between foo and bar", "bad character after foo", "bar needs to be at least 4 characters", etc.

With a single over-engineered regex the only error message you can do is "Something was wrong but this code is too stupid to tell you what"...

- Brendan

Reply Score: 2

RE[5]: Good article
by WorknMan on Wed 16th Jan 2013 16:32 UTC in reply to "RE[4]: Good article"
WorknMan Member since:
2005-11-13


A basic example is a 'trim' command. The following will remove spaces from the start and the end of the string:
s/(^\s|\s$)//
However it's actually computationally less efficient then having two separate replaces:
s/^\s//
s/\s$//


On the other hand, why not have a goddamn Trim function? It's infinitely more readable than any of this 's/' crap. You're trying to make excuses for a write-only language who's code looks like line noise by saying, 'Well, a good programmer should be able to read line noise' ;)

Edited 2013-01-16 16:35 UTC

Reply Score: 2

RE[3]: Good article
by galvanash on Wed 16th Jan 2013 02:54 UTC in reply to "RE[2]: Good article"
galvanash Member since:
2006-01-25

I had a computer programming teacher that used to prefer:

a = a + 1;

to

a++;

in the name of readibility!!!


If it is purely a readability argument, I see no reason to not use the increment operator, as long as it is alone or just being used in a loop construct. Throwing it into an array index or dropping it into a computation is confusing and dangerous.

Your teacher may have just been trying to avoid having to deal with explaining prefix vs postfix increment, how they evaluate, and all the confusion that usually leads to with a newish programmer. Sometimes teachers do things that seem silly and pointless when your still green around the ears but 20 years later you go "yeah, I get it now"...

Edited 2013-01-16 02:56 UTC

Reply Score: 3

RE[4]: Good article
by JAlexoid on Wed 16th Jan 2013 03:44 UTC in reply to "RE[3]: Good article"
JAlexoid Member since:
2009-05-19

A compiler would just use an inc command in both cases... Though a++ makes sense only with integer variables.

Reply Score: 2

RE[4]: Good article
by OzzyLondon on Wed 16th Jan 2013 15:30 UTC in reply to "RE[3]: Good article"
OzzyLondon Member since:
2011-11-18

a = a + 1 = a.operator+( T other )
a++ = a.operator++( int )
++a = a.operator++()

Three completely different function calls

Reply Score: 2

RE[5]: Good article
by Alfman on Wed 16th Jan 2013 16:02 UTC in reply to "RE[4]: Good article"
Alfman Member since:
2011-01-28

OzzyLondon,

"a = a + 1 = a.operator+( T other )
a++ = a.operator++( int )
++a = a.operator++()
Three completely different function calls"

You are absolutely correct. And the post-increment operator highlights a C++ syntactic hack in and of itself. Personally I'm a bit disappointed that the language designers reverted to such an ugly hack (passing in unused int parameter to distinguish between functions).

Reply Score: 2

RE[3]: Good article
by renox on Wed 16th Jan 2013 09:16 UTC in reply to "RE[2]: Good article"
renox Member since:
2005-07-06

Probably because he came from a Pascal background, in many case "readability" means "what I am used to read"..

I have a special thing for "a += 1;" myself: quite short and doesn't have the pre/post issue of "++".

Reply Score: 2

RE[3]: Good article
by tylerdurden on Wed 16th Jan 2013 18:33 UTC in reply to "RE[2]: Good article"
tylerdurden Member since:
2009-03-17

There is a very big difference between "not being able to do something" and "preferring something else."

a = a + 1 has little ambiguity to it, whereas a++ may have a rather ambiguous behavior: i.e. When does the value for a get updated? Is it implementation specific? etc, etc.

Reply Score: 2

RE[4]: Good article
by rr7.num7 on Thu 17th Jan 2013 17:39 UTC in reply to "RE[3]: Good article"
rr7.num7 Member since:
2010-04-30

There is a very big difference between "not being able to do something" and "preferring something else."

a = a + 1 has little ambiguity to it, whereas a++ may have a rather ambiguous behavior: i.e. When does the value for a get updated? Is it implementation specific? etc, etc.


Well, if you find that ambiguous, then perhaps you should find another profession. The behavior of the prefix increment is very well defined,and is a very, very basic topic that most books cover within the first 3-5 chapters.

Reply Score: 1

RE: Good article
by henderson101 on Wed 16th Jan 2013 10:39 UTC in reply to "Good article"
henderson101 Member since:
2006-05-30

IMHO, having a terminating statement like 'END IF' is a lot more elegant than having braces all over the f**king place.


No, no it's not. You try to maintain someone else's VB.Net app... "End If"'s (and "End ..." blocks in general) are complete crud. Braces are only complicated if you don't line them up correctly.. but most modern IDE's don't even make that hard. I far prefer '}' to working out which flavour of 'End ...' is missing in a VB method that some idiot made span 3 or 4 screens. Dometimes life is too short to not refactor, and moving VB code to C# is not all that hard. In fact, the last time I did that I fixed about 3 or 4 obscure bugs that VB introduced due to it's utter shit syntax (and this is with Option Explicit and Option Strict on.)

Having come from a Pascal background (but having done a lot of C++ in my BeOS days, ADA at university and BASIC before that), the "begin .. end" block teaches you much better practices than C's braces. There are plenty of places I will use a block where other programmers will not, mainly because it saves time in the long run.

And don't even get me started on semi-colons ;)


The semi-colon is a fairly unambiguous end of statement marker. If that is hard to understand, you are pretty much doomed.

Reply Score: 2

RE[2]: Good article
by Treza on Wed 16th Jan 2013 12:09 UTC in reply to "RE: Good article"
Treza Member since:
2006-01-11

I use both punctuation (C) and verbose (ADA) languages and tolerate both well.

The solution is a syntax colouring editor with very different colours for keywords and plain identifiers (not black and dark blue...)

The begin/end stuff becomes colorful patches surrounding black code.

Reply Score: 1

RE[3]: Good article
by henderson101 on Wed 16th Jan 2013 12:31 UTC in reply to "RE[2]: Good article"
henderson101 Member since:
2006-05-30

I use both punctuation (C) and verbose (ADA) languages and tolerate both well.


With ADA (83) we always had a "BEGIN" and an "END xxxx;" for all constructs, save possibly the "REPEAT... UNTIL ...", though it's been a good 20 years since I did any ADA and I don't remember it well. Same with Pascal (Object Pascal; Delphi.) With VB you don't. You get this:


If X Is Nothing Then
Something
Somethingelse
Elseif Blah = "Give up" Then
Somemore
Else
ShootYourself(DateTime.Now)
End If


Compare that to the C#


if (X == Null)
{
Something();
Somethingelse();
}
else if (Blah == "Give up")
{
Somemore();
}
else
{
ShootYourself(DateTime.Now);
}


Or Pascal


if (X <> Nil) Then //Or is it "X is nil"? I forget
begin
Something();
Somethingelse();
end
else if (Blah = 'Give up') Then
begin
Somemore();
end
else
begin
ShootYourself(DateTime.Now);
end;


The beauty Pascal is that the entire If is one statement with compounds, the beauty of the C# is that it is not (really.) Both have advantages.

EDIT: remembering to add the actual point: The blocks make it easy to see what belongs where, where as with VB and other non block delimited languages, it's all about context.

The solution is a syntax colouring editor with very different colours for keywords and plain identifiers (not black and dark blue...)

The begin/end stuff becomes colorful patches surrounding black code.


Yeah, that's kind of okay. But again, when the code spans 3 or 4 screens (bad coding practice, horrible to maintain) it's more about refactoring to a sane state initially. Syntax highlighting has come a long way. The first editor I used on a daily basis was Delphi 1 and the syntax highlighting was very simple and the code insight did not exist. You had to actually know what to type - a skill lost by many recent CS graduates.

Edited 2013-01-16 12:35 UTC

Reply Score: 2

RE[4]: Good article
by henderson101 on Wed 16th Jan 2013 12:37 UTC in reply to "RE[3]: Good article"
henderson101 Member since:
2006-05-30

More over


If X IsNot Nothing Then
Something
Somethingelse
Else
If Blah = "Give up" Then
Some more

Else
ShootYourself(DateTime.Now)
End If
End If


It's not hard before the lack of blocks starts to make the language unreadable and easy to misinterpret.

Reply Score: 2

RE[4]: Good article
by Laurence on Wed 16th Jan 2013 13:53 UTC in reply to "RE[3]: Good article"
Laurence Member since:
2007-03-26


Compare that to the C#...


That's badly formatted C#

I prefer the following:
if (X == Null) {
    Something();
    Somethingelse();
} else if (Blah == "Give up") {
    Somemore();
} else {
    ShootYourself(DateTime.Now);
}


In my opinion that is significantly more readable than any of the other examples you've listed.

Sometimes I concatenate the lines further:
if (X == Null) {
    Something();
    Somethingelse();
}
else if (Blah == "Give up") { Somemore(); }
else { ShootYourself(DateTime.Now); }

(this isn't the best of examples (and not helped by the formatting on OSNews), even I wouldn't concatenate specifically here, but sometimes it does aid readability.

edit:
The beauty Pascal is that the entire If is one statement with compounds, the beauty of the C# is that it is not (really.) Both have advantages.

You can use blocks in C-derived languages as well:

{
    if (X == Null) {
        Something();
        Somethingelse();
    } else if (Blah == "Give up") {
        Somemore();
    } else {
        ShootYourself(DateTime .Now);
    }
}


Edited 2013-01-16 14:10 UTC

Reply Score: 2

RE[5]: Good article
by lucas_maximus on Wed 16th Jan 2013 14:01 UTC in reply to "RE[4]: Good article"
lucas_maximus Member since:
2009-08-18

Actually apart from the lack of indentation it was correct. The Visual Studio default and the Microsoft Recommended Coding conventions all use that style.

http://blogs.msdn.com/b/brada/archive/2005/01/26/361363.aspx

Open braces should always be at the beginning of the line after the statement that begins the block. Contents of the brace should be indented by 4 spaces.

Reply Score: 1

RE[6]: Good article
by Laurence on Wed 16th Jan 2013 14:19 UTC in reply to "RE[5]: Good article"
Laurence Member since:
2007-03-26

Yeah I'm aware of that and I don't agree with it. I think it's less readable and the opposite of what developers in most other C-derived languages prefer.

Plus I object to Microsoft dictating how I -or any other 3rd party developer- chooses to format the braces in our own source code. That's my prerogative, not theirs.

Edited 2013-01-16 14:21 UTC

Reply Score: 2

RE[7]: Good article
by lucas_maximus on Wed 16th Jan 2013 14:40 UTC in reply to "RE[6]: Good article"
lucas_maximus Member since:
2009-08-18

Yeah I'm aware of that and I don't agree with it. I think it's less readable and the opposite of what developers in most other C-derived languages prefer


Well it is a matter of taste, so I tend to adopt what the language creators recommend, in this case Microsoft.

Plus I object to Microsoft dictating how I -or any other 3rd party developer- chooses to format the braces in our own source code. That's my prerogative, not theirs.


Well they firstly aren't, they are a set of suggested guidelines.

Unlike the Design Guidelines document, you should treat this document as a set of suggested guidelines


While I agree it is personal taste, pretty much all C# books, examples and third party libraries use that bracing style. Also Visual Studio and StyleCop default to type of bracing. It is what other C# programmers expect to see. I don't see any benefit in bucking the trend in the community, but as I said it is personal choice.

As I say, when I am doing Java or JavaScript I use the bracing style that you suggest. Java because it is what Sun recommended and JavaScript because of the issues with Semi-colon insertion.

Edited 2013-01-16 14:43 UTC

Reply Score: 1

RE[6]: Good article
by Nelson on Wed 16th Jan 2013 16:01 UTC in reply to "RE[5]: Good article"
Nelson Member since:
2005-11-29

I usually put braces on a new line unless the block is one line long.

if (someArg == null)
throw new ArgumentNullException("someArg");

The only exception I usually have to this is if its part of a larger if-the-else statement and the other blocks are multiline and have curly braces. Then I think:

if (this == that)
doX();
else if (x == y)
{
// ..
}
else
{
// ..
}

I think the obsession with vertical space is kind of silly in this day and age. I am much more sensitive to code that sprawls horizontally forever.

Besides, I often find new line braces more readable while less compact, whereas the opposite is true for a lack of braces, same line braces, or first brace same line.

At the end of the day though, it is extremely annoying when some full-of-himself programmer ignores the established project coding guidelines. I don't care if a monkey wrote it, if I'm going to be a part of a team, I'm going to follow their rules.

Reply Score: 2

RE[7]: Good article
by Laurence on Wed 16th Jan 2013 16:13 UTC in reply to "RE[6]: Good article"
Laurence Member since:
2007-03-26

At the end of the day though, it is extremely annoying when some full-of-himself programmer ignores the established project coding guidelines. I don't care if a monkey wrote it, if I'm going to be a part of a team, I'm going to follow their rules.


I hear you on that.

In the past I've written code that I've personally hated but it was correct in the context of the wider project.

That said, I have been known to completely rewrite smaller projects before, but those have been extreme circumstances (and there's usually been more wrong than just the use of blocks and braces hehe)

Reply Score: 2

RE[7]: Good article
by lucas_maximus on Wed 16th Jan 2013 19:44 UTC in reply to "RE[6]: Good article"
lucas_maximus Member since:
2009-08-18

I usually put braces on a new line unless the block is one line long.

if (someArg == null)
throw new ArgumentNullException("someArg");


I usually like putting the braces.

At the end of the day though, it is extremely annoying when some full-of-himself programmer ignores the established project coding guidelines. I don't care if a monkey wrote it, if I'm going to be a part of a team, I'm going to follow their rules.


Here here, we are having a meeting about coding standards just because there isn't any in our team.

I would like to make sure we use the Microsoft ones for C#, just because they are easily referenced and are well known. Also because we have a lot of juniors, when they look at code samples they are normally using the Microsoft syntax for the most part.

Reply Score: 2

RE[5]: Good article
by henderson101 on Wed 16th Jan 2013 16:14 UTC in reply to "RE[4]: Good article"
henderson101 Member since:
2006-05-30

"
Compare that to the C#...


That's badly formatted C#
"

Your opinion, and bear in mind, OSNews lost my indentation. To me, your code looks suboptimal for readability. I work in a large team, other people picking up classes and libraries I've written is essential. Standard style guides and conformity saves a lot of time and prevents prima donnas. Plus, having come from Pascal, those arguments just waste too much time. Suffice to say:

Lazy programmeritis:

if (x = y) then begin
   .....
end else begin
   ....
end;

I once had a co worker that used this one:

if (x = y) then
  begin
    ...
  end
  else
    begin
    end;

And this one:

if (x = y) then
  begin
  .....
  end
else
  begin
  ......
  end;

Borland style:

if (x=y) then
begin
  ...
end;



And that is just scratching the surface and not even dealing with tabs, etc. It's a holy war, not worth winging about.

For C#, the basic layout I use (and enforce here) is based on the standard Microsoft use in all of their sample code. Sorry if you don't like that, complain to someone who has write access to Microsoft's source repository ;-) Visual Studio also usefully formats this way - why fight the IDE?



if ( X == Null )
{
  Something();
  Somethingelse();
}
else if ( Blah == "Give up" )
{
  Somemore();
}
else
{
  ShootYourself( DateTime.Now );
}



I never use tabs, they are evil. I use 2 spaces for "Tabstop" because otherwise your code shoots off to the right at great speed. I would go for simple over terse single line every time. I tend to (recently) add in extra space in if/else if/method params. This is just a concession to a speed reading on a high res monitor. Text scans better.

You can use blocks in C-derived languages as well


Not exactly the same thing. In Pascal this is one statement:

if (x = y) then dosomthing else dosomthingelse(y);

and so is this:

if (x = y) then begin dosomthing; end else dosomthingelse(y);

and so is this:

if (x = y) then begin dosomthing; doanotherthing(x); end else begin dosomthingelse(y); end;


dosomething and dosomethingelse(..) are compound, as are the other examples. Like I said, the C syntax is sort of similar, but not exactly. Pascal thinks of the compounds as being part of a single statement, with compound elements. Where as C doesn't (IIRC.) The braces in C are just a way to create a block and the if/else links those blocks together. Semantics, I know. But look again at the basic Pascal version:

if (x = y) then dosomthing else dosomthingelse(y);

That is a pure statement, with no semicolon after the first clause. Geddit? :-) C would require 2 statements linking the blocks:

if (x==y) dosomething(); else dosomthingelse(y);

Reply Score: 2

RE[6]: Good article
by Savior on Sat 19th Jan 2013 15:27 UTC in reply to "RE[5]: Good article"
Savior Member since:
2006-09-02


if (x = y) then dosomthing else dosomthingelse(y);

That is a pure statement, with no semicolon after the first clause. Geddit?


I don't. How is that any different from
(x == y) ? dosomething() : dosomethingelse(y);
?

Maybe it looks a bit more cryptic than its begin/end counterpart if you embed these kind of statements into each other, but not by much. Stacking ternary statements is always ugly and unreadable, regardless of the language used.

Reply Score: 2

RE[7]: Good article
by henderson101 on Sat 19th Jan 2013 21:36 UTC in reply to "RE[6]: Good article"
henderson101 Member since:
2006-05-30

Because ? is an operator, not a key word and it doesn't really work in the same way - at least in c#. Plus in Pascal one can have as many segments in the statement as one likes:

if (x = y) then begin do1(); do3(); end else if (x = a) then do2() else begin do4(); end; //3 blocks

if (x = y) then begin do1(); do3(); end else if (x = a) then do2() else begin do4(); if (y = x) then begin do5(); do6(); end else do7(); end; //a 2 block embedded in a 3 block

Obviously, no one would format the code that way - it's just an example.


You can't really implement that using ? without a lot of unreadable complexity.

Reply Score: 2

RE[2]: Good article
by lucas_maximus on Wed 16th Jan 2013 13:15 UTC in reply to "RE: Good article"
lucas_maximus Member since:
2009-08-18

Normally most formatting problems can be sorted with the IDE.

TBH a lot of the problems you describe are more to do with the way the applications have been written and not the language itself. I am sure I can point you to some of the atrocities I have seen in C# (my favourite being the INullObject interface I recently found).

Personally I like VB.NET, while the syntax is odd you can write code pretty quickly. My main issue with the language is that it is difficult to see the difference at a glace between an array and a procedure/function.

A lot of newer developers especially those coming from Python or Ruby find the use of a semi-colon slightly arduous. There was recently a flame war between Douglas Crockford and one of Twitter Bootstrap developer over whether you should make of the JavaScript semi-colon insertion mechanism.

Edited 2013-01-16 13:16 UTC

Reply Score: 3

RE[3]: Good article
by Nelson on Wed 16th Jan 2013 16:05 UTC in reply to "RE[2]: Good article"
Nelson Member since:
2005-11-29

Ugh, that NullObject b.s is the kind of ridiculous over abstraction that you see from Java Programmers who move on to C#.

It is incredible the amount of gunk that Java programs have. Seriously. I'm convinced Java is just a collection of terrible design patterns looking for a problem.

Reply Score: 2

RE[3]: Good article
by henderson101 on Wed 16th Jan 2013 16:38 UTC in reply to "RE[2]: Good article"
henderson101 Member since:
2006-05-30

Personally I like VB.NET, while the syntax is odd you can write code pretty quickly.


Oh jesus.. no it's not! Here is an example:

Define a class and on that class create a public event


Public Class Whatever
  ...
  Public Event MyEvent(ByVal SomeValue As String)
  ...
  Public Sub RunHack(ByVal whatever as String)
    MyEvent(whatever);
  End Sub
End Class

Then in another class try this:


Public Class TwatFace
  ...
  WithEvents myHack as Whatever
  ...
  ...
  Public Sub ABadIdea(ByVal whatever as String) handles myHack.MyEvent
    MsgBox(whatever)
  End Sub
  ...
  Public Sub LetsBreakEventHandling()
    Dim fcukit As New Whatever
    myHack = fcukit
    myHack.RunHack("Shoot yourself now...")
  End Sub
  ...
End Class


What happens if we call LetsBreakEventHandling? Well, it should never compile... it does. It should probably freak out and crash, but you'll see a message box happily telling you "Shoot yourself now...". And I know all of this because the fcukwit programmers, on contract from India, that we used before I took over didn't know about "AddHandler Xxxxx, AddressOf Yyyyy".

Even with option explicit and strict on, you can do this:


Dim X as Integer
X = 99
Dim Y as Boolean ''uninitialised, so compiler decides

Select Case X
  Case 1, 2
    Something()
  Case 3, 4
    Somethingelse()
  Case Y
    WhatThef--kDoesThisEvaluateTo()
End Select


VB is dangerous, plain and simple and there's nothing you can do in VB that can't be done in a safer .Net language at a similar speed.

Edited 2013-01-16 16:43 UTC

Reply Score: 2

RE[4]: Good article
by lucas_maximus on Wed 16th Jan 2013 16:43 UTC in reply to "RE[3]: Good article"
lucas_maximus Member since:
2009-08-18

Look I am sorry you have a crap codebase, but the fact remains the same ... you can write bad code in any language.

Edited 2013-01-16 16:45 UTC

Reply Score: 2

RE[5]: Good article
by henderson101 on Wed 16th Jan 2013 16:48 UTC in reply to "RE[4]: Good article"
henderson101 Member since:
2006-05-30

Look I'm sorry you like VB, but the fact remains you can do better in just about any other language that targets .Net/CLR. VB is shit and it always was. VB lets you do completely unsafe things and even when you tighten it up to require as much safety as possible, it still lets you do ridiculously stupid things. A bad programmer can write reasonable code in C#, because there is a lot of padding to protect them, not least proper type safety. A bad programmer will hack together a horrible solution in VB.

This has nothing to do with the code base. I've dealt with very competent programmers using VB, and the C# translation is still far less unsafe due to the greater type safety and lack of silent casting and type munging that VB does in the background.

Edited 2013-01-16 17:08 UTC

Reply Score: 2

RE[6]: Good article
by lucas_maximus on Wed 16th Jan 2013 17:01 UTC in reply to "RE[5]: Good article"
lucas_maximus Member since:
2009-08-18

Look I'm sorry you like VB, but the fact remains you can do better in just about any other language that targets .Net/CLR.


Utter rubbish. In fact in some circumstances VB actually has some advantages over C# (XML parsing for example).

VB is shit and it always was. VB lets you do completely unsafe things and even when you tighten it up to require as much safety as possible, it still lets you do ridiculously stupid things. A bad programmer can write reasonable code in C#, because there is a lot of padding to project them, not least proper type safety. A bad programmer will hack together a horrible solution in VB.


Absolute crap, I have seen C# programmers just wrap stuff in Try ... Catch statements when encountering a null pointer exception. This is pretty much the modern equivalent of VB6's "On Error Resume Next", rather than deal with the condition sanely.

Or my personal favourite, catch the exception and throw e.Message ... so you lose the original exception.

This has nothing to do with the code base. I've dealt with very competent programmers using VB, and the C# translation is still far less unsafe due to the greater type safety and lack of silent casting and type munging that VB does in the background.


I am sure I could find quite a few other languages that are far worse. VB.NET is fine if you take some care about what you are doing.

Just look at the dailywtf.com, there is bad code is eveyr language and the two factors that always rear their heads

* Mis-management
* Moronic Team members.

Edited 2013-01-16 17:03 UTC

Reply Score: 2

RE[7]: Good article
by henderson101 on Wed 16th Jan 2013 17:27 UTC in reply to "RE[6]: Good article"
henderson101 Member since:
2006-05-30

Utter rubbish. In fact in some circumstances VB actually has some advantages over C# (XML parsing for example).


In your opinion. I've had zero issues parsing Xml in C#. The VB syntax makes my eyes bleed. The best integration I've seen is Actionscript.

Absolute crap,


If you say so. I think most sensible people that have encountered VB programmers would beg to differ. Even recently, a contractor was "let go of" because his code was pretty much the epitome of VB legacy over sense.

I have seen C# programmers just wrap stuff in Try ... Catch statements when encountering a null pointer exception.


Haven't we all? And I've seen exactly the same in VB - plus all the other cruft that language brings with it. Between rewriting a few methods with bad decisions regarding exception handling and dealing with crusty VB code, well - I know what I'd prefer.

Or my personal favourite, catch the exception and throw e.Message ... so you lose the original exception.


Seriousy? Here is how I deal with that: 10 minute talk including best coding practices handout, misconduct warnings (1 verbal, 2 written), bad yearly review if there's no improvement, removal from project work - probable contract termination. Do you know how often my organisation has had to go past first formal written warning? Probably 2 times in the last 15 years. This is why you interview carefully - with a formal practical element, pay for training when required and don't hire incompetent people. That's not to say mistakes are never made, but that's also why you give new hires a 3 month probation and make sure contractors are on weekly contracts until they have proven themselves.

I am sure I could find quite a few other languages that are far worse. VB.NET is fine if you take some care about what you are doing.


And you can go on making excuses. Or you can just not use it. I know which one is better for my business and saves me the most money.

Reply Score: 2

RE[4]: Good article
by Nelson on Wed 16th Jan 2013 17:24 UTC in reply to "RE[3]: Good article"
Nelson Member since:
2005-11-29



Oh jesus.. no it's not! Here is an example:

Define a class and on that class create a public event


I don't think what he said is untrue, just less true for some than others. People with a strong VB background have picked up VB.NET rather quickly (to my dismay, Id rather see it die a cold death, but ah well)

I think your counter-point underlines his point quite well though, in that WithEvents is a construct included in VB.NET for pure legacy reasons.

C# has the advantage of being able to learn from the mistakes of other languages, whereas when VB.NET was being developed, they likely valued VB familiarity over purity.

That's why you can do stupid things in VB.NET, but you can also do stupid things in C++, in Java, and in C# (Look at boxing before Generics for example).

C# not having as many ways to shoot your foot off is a testament to C# as a language, sure.


VB is dangerous, plain and simple and there's nothing you can do in VB that can't be done in a safer .Net language at a similar speed.


VB.NET is completely type safe.

Also, the switch statement with a boolean is probably going to evaluate to zero, because that's what a bool of false (default value for the bool value type) evaluates to when converted to an int.

Reply Score: 2

RE[5]: Good article
by henderson101 on Wed 16th Jan 2013 17:45 UTC in reply to "RE[4]: Good article"
henderson101 Member since:
2006-05-30

With regards to "WithEvents" - yes probably. But that's not what the MSDN says. As far as I can see, it's required when the "handles" clause is being used. That's not really legacy then.

VB.NET is completely type safe.


No it's not... not in the "you can't use the wrong type because it won't compile" sense of the notion. VB will happily munge and cast between integral types and Decimal/Double. VB will silently cast a Boolean to an integer. This should not compile, but it does:

Dim X as Boolean

Function WFT as Boolean
Return X
End Function

....
Switch Case Y
Case WTF ''This could be anything
....

Also, the switch statement with a boolean is probably going to evaluate to zero,


Yeah, probably. But when you have to run code to verify that fact, it's screaming "walk away" to me.

because that's what a bool of false (default value for the bool value type) evaluates to when converted to an int.


And the compiler silently casts the Bool to an Integer. That might be how VB6 worked, but VB.Net uses the CLR and so an explicit cast is required. How helpful VB.

Oh, and rewinding to "type safe".. try turning off Option Strict and Option Explicit and see how much worse you can make stuff... you don't even need to declare the return types of Functions... VB just guesses for you and silently casts the result to the type you assign the result to. Even with it on, you can still do everything else I mention. The first thing I do with VB code these days is look at the project properties and if it isn't already set, build it with Option Explicit and Option Strict turned on and fix all the errors. It is far, far too common to still find shops using VB.Net as if it was VB6.

Reply Score: 2

RE[6]: Good article
by Nelson on Wed 16th Jan 2013 18:24 UTC in reply to "RE[5]: Good article"
Nelson Member since:
2005-11-29

I agree with you that VB is terrible, but it doesn't make it type-unsafe because of it.

I think casting is more of a gray area and VB.NET definitely has more ambiguity. Its harder to know at a glance if something is correct.

C# does some implicit casting too, if you define an implicit operator overload. I'm sure VB.NET does something similar to manage to stay within the CLR sandbox.

What VB.NET does imho, is wrap bad ideas around syntax. Examples being like you said implicit conversions (which imo have always been a bad idea no matter the language) and implicit late binding.

VB.NET takes late binding, implicit typing, and implicit casts and muddies the waters into this incomprehensible soup of syntax.

However, it is still easy for VB developers to pick up VB.NET . That's always been the reason imo for VB.NET's existence. I'd never write any meaningful amount of code using it.

I think any time someone uses dynamic in C#, late binding in VB.NET or find yourself using some of these more weird features, they need to step back and think about what the hell they're doing.

Reply Score: 2

RE[7]: Good article
by lucas_maximus on Wed 16th Jan 2013 19:24 UTC in reply to "RE[6]: Good article"
lucas_maximus Member since:
2009-08-18

I agree that VB syntax isn't the best.

I have mostly written C#, Java, PHP and JavaScript. I have never coded in classic VB, So I tend to write VB like C#.

We have a lot of points in our code base (that is mostly inherited), where Try ... Catch is mis-used, and that is one of the better things I have to deal with.

* Functions doing more than one thing and multiple return values of the same type (usually string) which mean different things depending on how it is used.

* Very misleading variable names.

* Try ... Catch misused.

* Lack of understanding for some key OOP principles, a classic being two different types having say the first 5 properties and methods being exactly the same and having 2 or 3 properties that are different ... it is screaming to use inheritance, but it was just muddled together.

I could go on, but my main point was that any one of these problems aren't down to the language but down to lack of understanding of principles. I don't think any language magically fixes those.

Reply Score: 2

RE[6]: Good article
by henderson101 on Fri 18th Jan 2013 13:47 UTC in reply to "RE[5]: Good article"
henderson101 Member since:
2006-05-30

And don't get me started on "Modules"... Global static classes that are automagically pulled in to the scope of all classes in the same namespace... without the need to specify the module name. Ack!

Reply Score: 2

Comment by M.Onty
by M.Onty on Wed 16th Jan 2013 13:04 UTC
M.Onty
Member since:
2009-10-23

Thank you for posting this Thom. Its going to be very useful to me over the next month or two.

Reply Score: 2

As a long time C++ programmer...
by reduz on Wed 16th Jan 2013 15:04 UTC
reduz
Member since:
2006-02-25

And having written several game engines for games shipped to most plaforms.. this article is great.

I can definitely say that there is a point to be made here about C++. For this kind of things, C++ is still the best choice up to this day because the optimal ratio of OOP/Low Level/Performance/Code Size. Other languages bloat too much in one or more of these elements but C++ hits the balance.

The problem with C++ is that I think it's a language that takes around a decade of using it to fully come to terms with. Reading the source code of other people that is more experienced greatly helps but truth is that even if you read the full specification, you will still not understand what most features are really used for until you need them, and then it clicks.

Reply Score: 3

Comment by Nelson
by Nelson on Wed 16th Jan 2013 16:11 UTC
Nelson
Member since:
2005-11-29

I think people focus too much on naming conventions, curly braces, semi colons, and camel casing. There's not enough focus on the act of engineering something that's sustainable a few months down the road.

Too little attention is paid to the design of your object model (if you're oo inclined), the decisions made around multi-threading, and the relative costs of what you use in the language.

I've seen countless examples of people obsessing over for example how comments would be formatting, only to end up producing this over engineered bullshit code that is unmaintainable. But I guess itll keep them from scrolling vertically (on their text terminal I presume, because we magically traveled two decades back in time where that kind of shit matters)

And whats worse is that these questions are even more important in C++ where the compiler and run time make less security, resource, and correctness guarantees.

Its more important to know who owns what reference to what object, or what threads will call this method, what synchronization primitives we're going to use, how will we handle dependencies, or component failures, etc. This is the real bread and butter of programming.

Reply Score: 2

pretty good
by bnolsen on Wed 16th Jan 2013 22:35 UTC
bnolsen
Member since:
2006-01-06

Except for the formatting part our current code base uses much the same, with generally Qt type function names and naming conventions. Minimal use of inheritance, generally things are structs with functions, heavy heavy use of const everywhere.

It's a pretty effective style of coding, easy to maintain and debug. One technicality was the improper ordering of the const stuff and not constifying enough when pointers passed in

example parameter

type ** value

would be better expressed as:

type * const * const value

so the function won't hose itself if the function writer improperly reassigns one of the levels of "value" instead of just the contents.

Reply Score: 2

Too bad the engine sucks
by bassbeast on Wed 16th Jan 2013 22:44 UTC
bassbeast
Member since:
2007-11-11

I'm sorry but it does. There is a REASON why nearly every game out there runs on Unreal while ID tech 4 like the Cryengine is only used by the parent company, and that is because they suck.

You look at how much resources an average scene in Doom 3 used when there wasn't crap going on and you'd have to have a hectic battle going on for Unreal to use the same amount, they blew their resources on pretty lighting without remembering that pretty lighting isn't worth squat if there isn't things to put IN the pretty lighting. There is a reason why you could have the screen filled with demons in Doom 1 & 2 while 3 was nearly all one on one, and that was because ID Tech 4 simply chugs if you pile on the bad guys.

So while I'm glad the coders can be impressed by the code as a gamer I certainly wasn't impressed with the finished product. Doom 3 like Fear 3 is one of those games where I play the previous games all the time, the third one? Never, its just not fun and I find it quite boring.

Reply Score: 2

RE: Too bad the engine sucks
by Soulbender on Fri 18th Jan 2013 04:12 UTC in reply to "Too bad the engine sucks"
Soulbender Member since:
2005-08-18

ON what planet does the CryEngine suck? Planet Delusional? I'm not saying it's better than Unreal but it surely doesn't suck. Ran everything with great looks and speed even on a modest system. It's not based on idtech4, btw.
The Doom3 engine though...not so great in my experience. On a system that ran HL2 and Far Cry smoothly with good detail (using an Intel chipset) Doom 3 would struggle at the lowest supported resolution (640x480 or 800x600, can't recall) especially when a couple of enemies appeared. Then the frame rate dropped to something that felt like single-digits.

Reply Score: 2

RE[2]: Too bad the engine sucks
by bassbeast on Fri 18th Jan 2013 13:02 UTC in reply to "RE: Too bad the engine sucks"
bassbeast Member since:
2007-11-11

Read what I wrote friend it sucks for the amount of resources VS what you get for those resources. Look up the end battle of Crysis 1, its pretty infamous on how to this day that will cause many top end cards to choke because its so badly coded. There is even a fan made patch that will kick down the setting when you reach that ONE spot just because its so badly coded.

Again look at the facts, you have a good 90% of the games being made on Unreal, while CryEngine and ID Tech 4 are ONLY used by the parent companies...think that is a coincidence? Don't misunderstand, I'm not saying both engines can't put out a static scene capable of making you drool, THAT is not the problem. The problem is when you actually start to DO something in those scenes the engines blow through resources like a fat guy at an all you can eat buffet and end up using MUCH more than they should.

When I could take an HD4850 which at release was a top tier card at nearly $300 USD, which would epic "cool guys don't look at explosions" scenes with full AA and AF in any of the latest Unreal based games but it would have a scene that looked like a coder threw up on it in Crysis one when it got to the final battle? Something was very VERY wrong with that engine. Remember we are talking GAME engines here, making good static scenes don't count for much if the user has to spend half a grand just to get more than 15 FPS when you have enemies on the scene.

Reply Score: 1