> You were probably trained in the Object-oriented (and likely a bit of > post-OO) tradition. Most likely you learned > Java, and then possibly either C# or Ruby.
I started C-64 Basic, then I learned assembler, then C. After C, I have learned bunch object oriented and functional languages. Lately I have programmed in Typescript. I actually switch language to another all the time. Language is a tool and similar patterns can be implemented everywhere. >OO is not the only valid way to program. I agree. Usually, I'm thinking functional approach first, and if that doesn't cut, I look problem from dataflow perspective and after that I try OO. That usually solve the problem if everything else fails but that it is not of course only way. >I don't always agree with the OpenBSD developers (and sometimes I vehemently >disagree with their take on >things), but as a user I'm much happier with the >quality, consistency and predictability that OpenBSD provides, than >with some >project that's always chasing the moving target of the perfect programming >paradigm. I also like how directory structure is done in that scale and that consistency that ~everything is C and sh scripts. >and so perhaps more familiar to many modern programmers, but not intrinsically >or automatically more readable. I don't afraid of long functions. I also write long functions if I have fully implemented DbC or there is just lot to do. However, I do avoid complex functions. > and it's highly unlikely that any random group of programmers will be willing > to follow the style you were trained to > think is "best". "best" is not "best" if it is not possible to measure it any practical way. I can measure speed, I can measure memory usage, I can even measure how much implementation uses energy (which is actually good optimum for speed/memory usage) but I agree that coding style is often a matter of opinion. However, there is some factors that actually can be measured and those tells something about quality. Example, -Code coverage in tests (complex code is not easy to test!) -Cyclomatic complexity -Coupling Relating to coding style, it can't practically measure what is better name for function. Despite for that, I consider naming convention extemely important, because that is part of the process that is not so straightforward but I don't ever start argue how to shorten names or is camelCase better. I don't care as long as the style doesn't change. >OpenBSD defines (AFAIK) "results" to include safety of code, and/or freedom >from unanticipated side-effects (i.e. >bugs). I'm fascinated many ways the clean source tree in that scale and I have personal itch to implement methods to find bugs. Instead of pointing out single bug, I'm thinking about implementing methods to make much as possible bugs in code visible.
