Quote:Original post by kordova
Personally, to compensate I alter my code such that it never extends beyond the 78th character column. In the event that it has to, I will comment the closing brace to indicate its parent.

Hmm, I explicitly forbid that in my conventions - the reason being that if a code block is big enough to not fit neatly onscreen, then it's too big and should be broken up. So, adding the comment is patching the problem, not fixing it.

As a general rule, I believe that functions should fit on about a screenful of code. Anything larger tends to be unwieldy, and is also usually trying to do more than one thing, which is a bad idea. Anyone who really believes that they need more vertical space needs to either a) upgrade from a 13" monitor or b) focus on writing smaller, more focused functions.

As for the whole 80-column thing with conditionals, my convention calls for the following:

if(    foo&&  bar&&  (        baz    ||  blah    )){    // No beer and no TV make Homer something something}

for conditionals that are too hairy to break apart into smaller components. This style is also applicable to functions that take parameters with big names, like this (except with tabs stops at 4 characters):

	wxSlider *slider = new wxSlider	(		window,		wxID_ANY,		mValue,		0,		20,		wxDefaultPosition,		wxDefaultSize,		wxSL_HORIZONTAL | wxSL_LABELS | wxSL_AUTOTICKS | wxSL_TOP	);

I really like it, as it matches the general style of the rest of the code, and it certainly makes complicated conditionals easier to read. People that have come and worked for me frequently dislike it at first, and then really like it after a little bit.

Personally I use tabs only for indenting and I always use curly braces.

Quote:Original post by JasonBlochowiak

Quote:Original post by Way Walker

More keystrokes to modify? Modify from what to what? They both have the same number of characters and have whitespace in the same places: "space brace enter" and "enter brace enter". (Actually, many posters here seem to be omitting the space before the brace)

I started to explain this on my original post, but got lazy. :)

Moving blocks of code around, or dealing with block promotion or demotion, that sort of thing. I personally find using braces for single statements to be redundant, so that means that if a control block moves (say, when you're reversing a conditional), you need only select whole lines, not whole lines plus one character, so it's faster. Obviously we're not talking huge amounts of time here, but after actually writing the code, moving it around tends to happen quite a lot, especially during refactoring.

This is also why I like tabs - less keystrokes to navigate around.

If I used your style, I'd still select the return because it's usually cleaner to paste it. *shrug* different strokes (and what you describe isn't really anymore keystrokes, but it is a little more mouse travel).

And, like most micro-optimizations, this sort of thing doesn't really enter into my considerations. I spend more time thinking about the code than moving it around or even writing it.


@Red Ant: I have a strong, negative reaction to your extended function calls.

Hey, I'm just telling you what I'm using. I'm not asking you to follow my example. =p That said, what is it about way of calling functions with many / long args that you find so repulsive and why?

Quote:Original post by Red Ant
Hey, I'm just telling you what I'm using. I'm not asking you to follow my example. =p That said, what is it about way of calling functions with many / long args that you find so repulsive and why?

Hey, I'm just telling you that it makes me want to [sick].

[wink][lol]

It's not so bad, so long as it's consistent in your project. But, since you asked, I don't like it for a combination of two things:
1) () and {} look so much alike in some fonts (e.g. the one that appears in the source tags on my browser) that it looks to me like a new scope on first glance.

2) At first glance, I just see something there with nothing to tell me what, exactly, it is. It's just some user-defined token sitting in the middle of nowhere (with a scope opening right after it, no less! (see (1))).

When I see a function, I first scan it to get a feel for how it "flows". Loops, conditionals, that sort of thing. Basically, your function calls look too much like control structures on a first pass. It creates a disonance in my reasoning like a non-idiomatic goto would.

Quote:Original post by Way Walker

Quote:Original post by JasonBlochowiak

Moving blocks of code around, or dealing with block promotion or demotion, that sort of thing. I personally find using braces for single statements to be redundant, so that means that if a control block moves (say, when you're reversing a conditional), you need only select whole lines, not whole lines plus one character, so it's faster. Obviously we're not talking huge amounts of time here, but after actually writing the code, moving it around tends to happen quite a lot, especially during refactoring.

If I used your style, I'd still select the return because it's usually cleaner to paste it. *shrug* different strokes (and what you describe isn't really anymore keystrokes, but it is a little more mouse travel).

Mouse? While editing source? That's scary inefficient.

Quote:
And, like most micro-optimizations, this sort of thing doesn't really enter into my considerations. I spend more time thinking about the code than moving it around or even writing it.

Micro optimizations are appropriate for highly used operations - same for process, same for code.

Keep in mind that what's appropriate for one person working alone tends to be very different than what's necessary for someone leading a team. Even with quality senior staff, it's still necessary to do supervisory refactoring, and refactoring frequently involves moving code around.

Also, my general rule is that you should be embarassed by code you wrote 12-18 months ago. If not, you're not learning fast enough. :) That being the case, I'll go back into old code (when appropriate) and rework it.

Also also, I've yet to see an environment in which the requirements are static enough that code targeting the original spec survives unscathed into the final product, except maybe the really trivial stuff.

I've always used the 2nd.

FWIW, on all of the commercial games I worked on for big publishers, they mandated the second style on us. YMMV.