------------------------------------------------------------------------ >Or the most straightforward and obvious way to break out of a switch >in a loop.
True. It is also good way to model exeptions. I take my word back, this may be most elegant way to exit that loop in this case. >Variables defined predictably at the start of the function, as the >convention is in BSD code. That is good convention. But while the function is so big, it is harder to read. >You then also need to shovel >data back and forth between these functions. Not necessarily. When the program is this tiny, single file source, it may not so bad thing to use global scope for that shared data. >Two hundred lines is hardly long I've used to write less than twenty lines functions. >How would you improve these names? Naming is ok me, but I may add comments what they are used for. > It sounds like you're just trying to take snippets of code out of > context and declare them bad because you're not reading the rest of > the code? I don't say that this code is bad. I think it is good gode, but there is plenty of room to improve readability. > Much in the same manner that splitting the function into > a few dozen would only make it harder to see the code for what it is. And when the lower level details are hidden, it is easier to see what the code does. This is idea of abstraction. > Mind you, the code isn't written for a first-year comp sci course > where the students need annotated twenty-line snippets to help them > come to grips with the basic syntax and structure of a computer > program. I like to write self documenting code. My practice is to comment ~all functions with block comments, all parameters (with ranges), return values, exceptions, external effects, all variable declarations (with ranges). And, I prefer to write tests first. > Again trying to please some quality metric? Yes, cyclomatic complexity. If that is high, it is usually good sign that code needs refactoring. > Did you intend to achieve better cohesion and lower coupling by > breaking the function into a dozen small functions that appease > whatever metric you're using? No, lower CC index per function instead. This kind of refactoring often reveals opportunities to increase cohesion in more complex programs and helps to reduce the amount of code. > Of course, I'm a nobody to say how this code should look, but it looks > fine to me; and so far as I can tell, it's not broken. Don't fix it > if it's not broken. Yes, it is considerably harder to refactor because there is no tests for that. I think that should be starting point. > But if your comments about the current code are any indication of what > your ideal version would look like, I'm not sure there are many who > would be willing to commit it. I think that it is not defined enough unambiguously, how ideal code looks like. It reduces motivation to improve code better, if it is not defined, what is better. style(9) is good, but it would be better if there is reference component that is optimized to perfection, including tests, naming conventions, file hierarchy etc. Then ALL code changes and new code can be compared to that reference, and that reference code can be used to build templates & automated testing.
