Can you two please continue this spam off-list, or at least in misc? On 24 September 2014 23:52, Matti Karnaattu <mkarnaa...@gmail.com> wrote:
> > 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. > > -- The best the little guy can do is what the little guy does right
