C unnecessary function prototypes

I shall continue to put curly braces on single lines - and you can't stop me! :p
If it helps you ... and more importantly, if it helps the other people who are working with the code you write (and will do so in the future, including your self 10 years from now), then more power to you!

On the other hand, if you are doing it under duress because the "elders" at your company are having a "jihad" (as Kent correctly points out) and using coding rules as a tool for pressure and oppression, then I fee sorry for you. And if you're only doing it out of tradition, you should maybe reflect, try some other options, and see whether you want to change. To quote either Gustav Mahler or Karl Boehm: "Tradition ist Schlamperei" (tradition is sloppiness).

And to Kent's other point: Different domains, different expectations of collaboration and code quality, and different ways of thinking all call for different coding styles. I'm myself finding that as I age, and my brain shrivels up, I enjoy long and internally complex pieces of code less. But certain problems are complex, and trying to break them down into small pieces only obscures the complexity.

Problem du jour (now solved): A microcontroller has two multi-color LEDs attached, which in normal operation show the state of the system by a steady color. It also has three pushbuttons, red green and blue, which can change the state. For safety, you have to press the button for a whole second before any action is performed. To make things more complex, the three buttons have to control four functions, so pressing red and green at the same time is a fourth action. To give the user feedback that they have pressed the button and that an action will happen soon, the LEDs both change once you press a button: The moment you touch a button, they change from their steady state to a fast blinking, in the color that matches the button (like blue-off). If you press the combination button, the blinking is red-green. After one second, to confirm to the user that the button press has done its function, the LEDs change from a fast blinking to a smooth wave (for example blue going smoothly dim-bright in a 2 Hz cycle). The actions can take anywhere between zero and about 20 seconds, so the smooth wave will be present for at least 5 seconds as a visual confirmation. As soon as the action has completed, the LEDs go back to their steady glow (probably in a different color than before, since red/green have the meaning off, auto and disengage). Except for the blue button, which causes the LEDs to continue doing their smooth wave until everything turns off (the blue button means shutdown and cuts power, eventually).

Turns out this is actually a nastily complex piece of code to write. In particular if you consider error and unusual conditions. What should happen if the user presses a button for 0.2 seconds only (answer: it blinks fast while pressed, then goes back to steady, and the button is otherwise ignored). What should happen if the button remains pushed for a long time (answer: the action is performed, and then the smooth wave keeps on until both the action is completed, and the button is released). What if the user pressed an invalid combination (answer: haven't figured out a good answer yet, for now the LEDs just turn off until the buttons are released, and both button presses are ignored). Too bad the system is too small (just a few inches) to have a text display. And too bad an audio indicator wouldn't work (the control box is right next to large pumps and a substantial gas engine). So for now this crappy user interface is the best I can do.

This code is working now (507 lines of Python); I'll write tests for it (both with mocked hardware, and on a lab bench test system with buttons), deploy it into prod, wait for a month or two of real-world experience, and then add sending e-mail notifications of bizarre things. Like wrong button combinations, or a button remaining pressed for an hour, which probably means someone leaned a shovel against the button on the control panel.
 
I shall continue to put curly braces on single lines - and you can't stop me! :p
I also prefer non-Egyptian braces. Power brother!

I find this style of Egyptian braces ironic:
C:
void A(int x, int y) {

 // some code goes here.
}

Clearly you see a need for space between the function signature and the first line of code... How about we go ahead and slide the opening brace right into that empty line?
 
[…]
Sometimes doesn't work, and sometimes fails spectacularly. In my previous job, we had a 6000 line function. It was perfectly readable, mostly bug free […]

Admittedly, that is the extreme example, and I've never seen anything this complicated. But that function handled an extremely complicated work flow (which involved humans, hardware and software interacting).

Sure, we could have completely recoded it, for example into a state machine, with a pool of state at the center, and a variety of control flows (perhaps interlocked threads) handling the interactions. But orchestrating all these participants would have been hell, and bug prone.
[…]
So you had a “extremely complicated workflow”, which was coded into a 6000 line monstrosity. That makes me wonder: What do you mean by “perfectly readable” then? —

I bet that code was not audited by an authority for mission critical devices, because these authorities (like the FDA in the USA) insist of having a (a) software architecture, (b) automated and documented tests, (c) explicitly formulated risk-aware requirements.

You hint at the solution for avoiding such 6000 line “functions” yourself: State Machines, Pools, Dataflows, etc. …

Granted, such an architecture makes the complexity of the task glaringly evident, but don't shoot the messenger because of the message.
 
Back
Top