What, they charge for white space where you come from?
Do you also think parens and semicolons slow down program execution?
They charge more for bigger screens, yes.
I like being able to see a lot of code on my screen at once. The more useless whitespace there is, the less actually meaningful code I can see. This is especially important on my laptop.
I am all for using whitespace for readability - but I don’t see how separating the method declaration / if condition / whatever from the actual code by one line makes it any more readable. To me, a blank line between two lines means that the two lines are somehow separated in purpose.
Another pet peeve of mine - people who insist on truncating their code to an 80-character line width. We’ve all got widescreen displays these days - use them! 120 characters gives you a lot more freedom, especially if your variable names are as descriptive as they should be.
So other people can read the code. You put braces on the next line for the same reason you don’t nest multi-line ?: operators. Just because something works and you can read it doesn’t mean it’s stylisticly superior. It gives me a headache when people code as if whitespace is some scarce resource to be used as sparingly as possible.
It’s the same as reading some jackass’s resume in email styled in 6 point font and no margins at all so that if I happen to print it, it will all fit on one page. I don’t want to read that shit, and I certainly don’t want to edit it.
minor7flat5, I introduce you to the .NET ?? operator
I’m not really a programmer, but what if you check and then uncheck the box? When you check it, someFlag is set to true. When you uncheck it, you’d need the else statement to change it to false, wouldn’t you? Or would you reset the flag elsewhere?
Ooh, yeah. I knew a guy who’d do something like this:
foofunc(abc, def, qrx, tuv) ?
(foofunc2(yada, ya, ya, yada) ?
someparam :
otherparam) :
bar;
That’s a good question - and the reason why this situation comes up more often than one might expect. The conditional provided in the example could easily be replaced with:
someFlag = checkBoxIsChecked;
When the checkbox is checked, someFlag will contain “true”. When the checkbox is not checked, someFlag will contain “false”.
LilShieste
I think my eyes just threw up, a little bit.
LilShieste
Preach it. I’d actually edited for clarity. A real example would have been on one (120 char) line.
[QUOTE=Derleth]
[li]Fuck Scheme for breaking car and cdr: I don’t care about the Lisp-1 v. Lisp-2 debate. I like Lisp-2s because I like to define my own names, but Lisp-1s are how non-Lispers think. However, there was no reason for Scheme to make car and cdr fail on the empty list. None. It is neither an aesthetic improvement nor a result of something else. Steele knew better. He had to: He implemented Scheme and predecessors in real Lisps.[/li][/QUOTE]
This is a very piddling matter, but let me just say, I find it an aesthetic improvement. car and cdr should be the least defined operators whose product is a right inverse to cons. There’s no clean reason for them to be applied to anything other than a cons cell, and if the type system isn’t strong enough to prevent them from being so applied anyway, then they need to at least man up and produce an error. Silently producing some arbitrary value just for the sake of misguided “convenience” is nothing more than a failcess.
All these posts and no one mentioned the extra spaces after and before parentheses?
if ( condition )
{
Bool( string ) = true;
}
else
{
Method( Int32 ) = String( Bool );
Bool( string ) = false;
}
Seeing hundreds of lines of code like this drives me batty.
Also, excessive commenting. I’ve seen code where, for every line of code, there were 5 lines of comments.
Sorry, I meant “left inverse”, of course.
Well, then. See that you keep your wits about you in the future. 
:smack:
That’s pretty obvious now that you point it out.
At our C++ shop, I have a boss who hates and fears templates. We put up with it until one day we found this in our repository:
#define DEFINE_BITVECTOR(type) struct type#_set \
/* ... implementation of a type-generic bit-vector elided ... */
}
DEFINE_BITVECTOR(uchar);
DEFINE_BITVECTOR(ushort);
We all got together and held an intervention after that.
While I’m here, fuck the C++ standards committee with a walrus for inventing the export keyword without any idea of how to implement it. Now we’re boned: Comeau actually supports the damn thing so we can’t get rid of it, but Microsoft and the Gnu people say they never will. The one bright spot is that we’ve got a new version of the standard coming up, so if we’re lucky they’ll find some way to…accept a whole swarm of new, unimplemented language features. Awesome.
And oh yes, my favorite brace style in brace-y languages is
if(foo) {
Bar()
}
…after the Ruby style:
if foo
Bar()
end
# Although, technically, the idiomatic Ruby for that is:
Bar() if foo
Blah blah blah, saves-vertical-space-associates-the-branches-of-the-block-with-the-branching-condition-cakes.
gcc will print it out, too, even without optimization enabled. It happens because the C++ standard allows compilers to do constant value propagation on variables declared const.
My guru friend tells me the following, which I think agrees with you:
Which makes sense, really; the code attempts to do something self-contradictory (modify a const), and the compiler complains. If you cast away the error message and proceed anyway, the results are going to be confusing in some way, through no fault of the language or compiler. While the exhibited behaviour is certainly weird, it’s hard to see any other behaviour being much more intuitive. You either do what the compiler did, end up discarding data, or have const variables changing. None of the options is ideal.
And yes, “thingamyjig” is a technical term. 
I assume all of you have already seen this?
Program for job security!
I especially like this one:
