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!I shall continue to put curly braces on single lines - and you can't stop me!![]()
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.