“Maybe you’re under the impression that the ONLY way to seperate code into logical blocks is to split them into single-use subroutines. But it’s not true. Anonymous blocks are just as effective at conveying the cohesion of function steps – if not more so.”
Not so. Breaking code up with whitespace relies on programmer judgement to keep the pieces working independantly. When you break the code into subroutines the compiler enforces this. It also forces you to declare the parameters that a block of code requires, it makes reuse easier if it should become necessary and it simplifies changing the order of execution. Most importantly, if it were broken into subroutines, it would be possible to tell at a glance what steps were executed when that function was called instead of forcing the reader to scroll down through several screens of code culling out the meaningful comments.
"I think on these points we’re going round and round here … "
Agreed. Its not that that function was particularly hard to read, or that I haven’t seen much worse, its that in my view it would be more readable and maintainable if it were broken into seperate functions. In my experience, A relatively sane function like that, when monkeyed with by a half dozen other coders of varying abilities, can easily morph into a real monster. But like with most stylistic arguments, I fear we’re doomed to not agree on this.
What I find interesting is how backward non-OOPs are. You dealing in a non organic paradigm. C is meant for low level programming and almost nothing else. Move on to managed code thank you. Being able to set up objects, build on others objects, and being able to isolate functionality (remove redundant functionality patterns) is more productive.
When I looked at the code sample I thought geez was this written in the 80s? C is not a modern language.
If you put the name of the function on a new line, you can search for the function definition (and nothing else) using a regular expression. For example, ^make.
Personally, I thought the jam source code was very pretty…
“Use variable names like i and j.
Surely thats heresey.”
I agree to disagree. I always use 1 letter variable names for any looping constructs. This immediately tells me that this variable is a throwaway local that is being used by a loop. This is a good convention and it saves on typing.
Is this better than naming the variable loopcountertoparsestring? This variable name is definately more descriptive than i or j. But consider:
arrayofitems[i]
vs.
arrayofitems[loopcountertoparsestring]
I find the first easier to work with. Maybe its because that is they way I always have written it.
I’m surprised nobody seems to have commented on the more obvious problems in the example C code.
One-line loops and conditionals don’t use {}s, which I guarantee will eventually bite you on the ass. And not in the good way.
2- and 3-line comments for one line of code (and a debug statement). That’s not commenting, that’s obfuscation. Don’t make me pay attention to stuff that doesn’t help. If the block you need to comment merits a multi-line comment, make it a method. Oh, right, C: function.
“if(” isn’t a keyword. “if” is. Keywords deserve their own space. That’s why they’re keywords.
Several people have commented that make0 is too long: damn straight. That shouldn’t have made it past an initial code review. Even if I was reviewing my own code.
Wow, that whole FATE chunk sure is a PITA.
“Don’t even think of deciphering this.” And that’s with the over-commenting? giggle “Insert c in front of s.” Sure seems like some trivial variable naming could have made things a lot clearer.
C, while relatively ugly compared to some languages, can still be beautiful in its simplicity and bare-metal mentality.
Over-commenting, or comments of suspect usefulness, make things worse.
“Not really. It’s straight line code. Chopping it up into a half-dozen mini-functions wouldn’t add a bit of clarity; it’d just force you to yo-yo around to see what’s happening.”
BS. It’s very unusual that you have to understand everything that’s happening in a chunk of code all at once. Breaking up functional units allows you to focus only on the parts you actually care about.
Editors/IDEs with configurable folding can do much the same thing, but I’d still rather have it broken into individual components.
I’d rather read code well-abstracted code with useful function names and break things down into small units. I don’t want to wade through a hundred lines that have nothing to do with what I’m interested in.
While it’s a PITA to keep harping on this small code chunk, there are plenty of functional units that could easily be stripped out.
Name them something useful and the useless comments go away and algorithmic comments can be made in function headers, where they belong, waiting to be extracted and formatted.
And I’ll pick on whatever whitespace conventions I want We should talk about tabs vs. spaces now
We should talk about tabs vs. spaces now 