I started following HMH back in December and my coding style has been rapidly mutating towards Casey's. He makes sense, what can I say.
Now, here's the problem. I started programming twenty years ago and, although the sorts of programs I've written over the years are nothing like videogames, I can't help feeling a bit hurt every time I renounce yet another long-held coding habit.
So I've tried rebelling a few times ("I'll do A, but I'm never doing B"), only to find out that once I embraced A, the set of trade-offs that made B unappealing shifted under my feet and turned my reluctance into an uphill battle.
Here's the story of my latest and most traumatic conversion. It just happened one hour ago:
Being pretty much sold on compression-oriented programming (A), I was happily hacking inside a 300-line function inside a doubly-nested loop, part of the scope of a case (kind of tame by Casey's standards, but hey, I'm getting there). In order to remain inside my 80-character row width limit (B*), I was starting to contort variable names, new-lines and pretty much everything I could get my hands on.
Doing that sort of thing once a day is not a big deal, but I was already jumping through that hoop maybe fifteen times a day and every change of gears from meaning to formatting messed with my focus big time. I just broke. I opened my .vimrc and edited a line that's been there for eleven years in order to allocate 120-character-wide buffers. It was that or going for single-letter variables.
Now, all my code looks like the tetris game of a patient of hemispatial neglect. There's so much room there that I want to hang pictures. I hope you're happy now, Casey.
* My self-imposed 80-character limit stemmed from:
- Using huge fonts to reduce eye fatigue
- Working mainly on smallish laptops
- Having spent many years mainly scripting in python (80 characters is an almost universal standard among pythonistas)
Now, here's the problem. I started programming twenty years ago and, although the sorts of programs I've written over the years are nothing like videogames, I can't help feeling a bit hurt every time I renounce yet another long-held coding habit.
So I've tried rebelling a few times ("I'll do A, but I'm never doing B"), only to find out that once I embraced A, the set of trade-offs that made B unappealing shifted under my feet and turned my reluctance into an uphill battle.
Here's the story of my latest and most traumatic conversion. It just happened one hour ago:
Being pretty much sold on compression-oriented programming (A), I was happily hacking inside a 300-line function inside a doubly-nested loop, part of the scope of a case (kind of tame by Casey's standards, but hey, I'm getting there). In order to remain inside my 80-character row width limit (B*), I was starting to contort variable names, new-lines and pretty much everything I could get my hands on.
Doing that sort of thing once a day is not a big deal, but I was already jumping through that hoop maybe fifteen times a day and every change of gears from meaning to formatting messed with my focus big time. I just broke. I opened my .vimrc and edited a line that's been there for eleven years in order to allocate 120-character-wide buffers. It was that or going for single-letter variables.
Now, all my code looks like the tetris game of a patient of hemispatial neglect. There's so much room there that I want to hang pictures. I hope you're happy now, Casey.
* My self-imposed 80-character limit stemmed from:
- Using huge fonts to reduce eye fatigue
- Working mainly on smallish laptops
- Having spent many years mainly scripting in python (80 characters is an almost universal standard among pythonistas)
Edited by Miguel Lechón
on
Reason: list formatting
You should take a look at clang-format. We use it at work, and it keeps us from having to do any of the boring minutiae of managing line limits. I have it hooked up to Ctrl+K in Vim -- it's so fast, I reformat lines while I'm typing them!
I've given clang-format a try and I suppose it would have saved me some time when I was still using narrow editing buffers. Right now, with wider buffers, vim's auto-indenting is pretty much all I need, but thanks for the suggestion!
To reduce the length of lines, I sometimes like to format function calls like this:
(I suppose the closing parenthesis could also be on the same line as the last argument, whichever you prefer.)
Similarly for function declarations:
I actually use this format for all function declarations, not just long ones. It takes a bit to get used to, but has some advantages. First, the return type is clearly separated from the function name, on its own line (with the optional static). Second, each argument is on its own line so the eyes don't have to hunt for the commas to parse them. This makes it easier to tell at a glance how many arguments a function expects and what their types are. Adding, removing and reordering arguments is easier as well, since most text editors have quick and easy operations for removing, inserting and moving lines around.
1 2 3 4 5 | int value = longFunctionName(
longArgumentName,
evenLongerArgument,
seriouslyWhyAreThoseNamesSoVerbose
);
|
(I suppose the closing parenthesis could also be on the same line as the last argument, whichever you prefer.)
Similarly for function declarations:
1 2 3 4 5 6 7 | static int
functionName(
int arg1,
int arg2
) {
// Function body
}
|
I actually use this format for all function declarations, not just long ones. It takes a bit to get used to, but has some advantages. First, the return type is clearly separated from the function name, on its own line (with the optional static). Second, each argument is on its own line so the eyes don't have to hunt for the commas to parse them. This makes it easier to tell at a glance how many arguments a function expects and what their types are. Adding, removing and reordering arguments is easier as well, since most text editors have quick and easy operations for removing, inserting and moving lines around.
Edited by Benjamin Kloster
on