3 ms·

nah. I think you could quite easily quantify the effect various tools have on a code base; adding unit tests, using a repl, static vs. dynamic etc. on the vari

nah. I think you could quite easily quantify the effect various tools have on a code base; adding unit tests, using a repl, static vs. dynamic etc. on the various aspects of your code: - How quick/easy is it to add new features? - How often do you add new bugs? - How long does it take to fix bugs? ...but I think you could also look at the impact individual bad actors (the 'dont care' programmers) have on the same code base. Now, because the 'dont care' programmers hack out rubbish at the speed of light, it may superficially appear that the net impact on the code base is balanced; more features, more bugs... but that rubbish slowly spreads out into the code base, and incrementally trigger a cascading bug creation rate for all the programmers. Now, if you want to suggest that tools can add enough value to overcome the negatives from having rubbish programmers, I'm all ears, because I've never seen a tool that can do that. The bad programmers just abuse the tools or ignore them. So... in that context, I think its fair to say, more tools really achieves nothing much, when bad programmers and bad programming practice results in such catastrophically bad outcomes for software. Maybe, if you can make your tools nice enough and add enough processes you can kind of force bad programmers up a notch. I appreciate that; but the question really is, why are there so many programmers who are so rubbish? Why do they never seem to get better? Why don't they care? Do you really think you engineer a solution to that? ...because I think it's a social problem, not a technical one. Maybe some tools can help, and maybe not everything Uncle Bob says is gospel... sure; but I think this is just stupid: > Uncle Bob gives terrible advice. Following it will make your code worse. I think history has objectively shown this is false; but of course, you're welcome to have your own opinion without any substantive basis other than that opinion itself if you like.

Ace17 9y ago
> Now, if you want to suggest that tools can add enough value to overcome the negatives from having rubbish programmers, I'm all ears, because I've never seen a tool that can do that. The bad programmers just abuse the tools or ignore them. So much this. This perfectly matches my experience (and desperation). Bad programmers will do their best to work around tool-imposed limitations that they don't understand. And these workarounds will generally increase code complexity! - Force a minimum coverage ratio: they will create useless tests that don't check anything (without assertions). - Force a maximum on function sizes: they will split their methods halfway and pass the whole local state through parameters. - Force a "no-global variable" policy: they will create singleton classes. - Force a "no public member variable" policy: they will create set/get methods for their private members. I'm not advocating for any of the above restrictions, they do more harm than good. Please, give me something I can put into my CI server that checks for bad coding practises, something that checks that the code stays SIMPLE. Fact: you can inject a new disabled feature into a C codebase with zero risk of introducing any bug ... by wrapping your 50 modifications of the codebase into #if/#endif clauses. Guess what? This will make the code a lot more complex, will slow down every developer, and will increase the likelihood that they create bugs in other features. Finding bugs is only the tip of the iceberg. What I want is to decrease the probability of their apparition, by keeping the code simple. Bugs and code complexity are correlated. Only targetting bugs will break this correlation, and we will be left with correct rigid code (very hard to modify). Even if my compiler perfectly prevents me from breaking anything, I still want to be able to add a feature in a reasonnable time. Let me summon Rich Hickey here: Simplicity Matters, and "nobody drives on the highway by bumping into the guard rails".

Ace17 9y ago

> Now, if you want to suggest that tools can add enough value to overcome the negatives from having rubbish programmers, I'm all ears, because I've never seen a tool that can do that. The bad programmers just abuse the tools or ignore them. So much this. This perfectly matches my experience (and desperation). Bad programmers will do their best to work around tool-imposed limitations that they don't understand. And these workarounds will generally increase code complexity! - Force a minimum coverage ratio: they will create useless tests that don't check anything (without assertions). - Force a maximum on function sizes: they will split their methods halfway and pass the whole local state through parameters. - Force a "no-global variable" policy: they will create singleton classes. - Force a "no public member variable" policy: they will create set/get methods for their private members. I'm not advocating for any of the above restrictions, they do more harm than good. Please, give me something I can put into my CI server that checks for bad coding practises, something that checks that the code stays SIMPLE. Fact: you can inject a new disabled feature into a C codebase with zero risk of introducing any bug ... by wrapping your 50 modifications of the codebase into #if/#endif clauses. Guess what? This will make the code a lot more complex, will slow down every developer, and will increase the likelihood that they create bugs in other features. Finding bugs is only the tip of the iceberg. What I want is to decrease the probability of their apparition, by keeping the code simple. Bugs and code complexity are correlated. Only targetting bugs will break this correlation, and we will be left with correct rigid code (very hard to modify). Even if my compiler perfectly prevents me from breaking anything, I still want to be able to add a feature in a reasonnable time. Let me summon Rich Hickey here: Simplicity Matters, and "nobody drives on the highway by bumping into the guard rails".