Some random thoughts:
#1 Anyone who has worked on a large code base knows it's littered with TODO comments. Either do it or don't do it.
#3 Yet again half of Knuth's quote. If performance matters don't wait. If it doesn't then it doesn't. But after the fact optimization rarely happens, is more expensive and won't get you there. Don't do unnecessary optimization at the end of the project and don't them them in the beginning either. The necessary ones need to be thought out in advance (choice of right data structure, algorithms, tools) and are difficult to change after the fact.
#4 Arguing about style isn't a good use of time. There has to be some measure of consistency/coherence in a code base but it's easy to take too far.
#7 There's a fine line between a best practice and a cargo cult. Don't do something just because it's a best practice. Do it because you understand the relationship between the practice, the circumstances, and the results.
#17 There's a positive side to personal attachment to the code. You care about it. Also did #34 just state the opposite?
The worst optimizations I've ever seen are pre-optimizations. I've seen many designs, in fact, that were attempting to prematurely optimize and inadvertently caused future performance problems.
The best optimizations, by contrast were done at the end of a project where the default was "keep the code clean", not "try to predict future performance issues".
The code that iterates over items and skips on condition isn't any easier to read or detect errors than access via bsearch or similar subroutine. In fact, straightforward code tends to introduce errors. Optimizations and correct naming [and thus centralized control] of routines are pretty close to each other, and when you give a name to get_cached_col_offset(col, last_known_col, last_known_offset) or have explicit caching iterator, the code looks much readable than for(y)-for(x)-everywhere mess with different off-by-ones and overflows in each block.
Where is that line separating dumb code from clean code?
Edit: wording
I don't need data to tell me how to run a team, I need people who can discuss their experience like grownups and reach a palatable consensus on how to operate and then get on with it.
CS has far too many clever people passing off random opinions and preferences as Best Practices, and far too little empirical testing of anything anyone recommends or does.
https://www.amazon.com/Making-Software-Really-Works-Believe/...
> Otherwise please use the original title, unless it is misleading or linkbait.
Quoted from https://news.ycombinator.com/newsguidelines.html - I think this is pretty clearly a case where it is preferred to not use the original title.
Wait, what?
'Be strict about best practices even if they seem negligible' is horrible advice.
I often run into cases where something needs to be laid out differently to what the 'best practices' recommend for the sake of readability. I've worked with several popular linting configs for Javascript and over time I've found myself or my team paring them back to just the basics in order to make them usable.
Even the basics provide dubious value in my opinion. A basic linter provides great value if you hire droolers that can't figure out basic indentation. But if you're doing that then you have serious problems and no amount of corralling is going to save you.
Past that, I've never once seen any real value come from something like mandating semicolons, or a lack thereof. I feel like actually caring whether the file you're opening has or doesn't have semicolons is a clear sign of an inexperienced programmer. It makes zero difference to my workflow, and IME experienced devs will just carry on whichever style is already in place without even a second thought, linter or no.
In my experience the absolute worst case scenario in terms of code readability (assuming you haven't hired anyone completely incompetent) is when your dev team is twisting themselves in knots trying to adhere to linter rules when they should just trust their instincts about what is readable and what is not.
In other words, for this sort of style stuff, a formatter that everyone uses is much better than either a linter or a "trust your instincts" approach.
Of course, a tool like 'go fmt' is far superior to common linters, as most third party packages look the same as your own code.
1: https://www.psychologytoday.com/blog/in-therapy/200907/the-d...
2: https://www.quora.com/Did-Einstein-really-define-insanity-as...
Or is it a quick way of making sure you have a codebase littered with TODO comments? :D
(Though even there, at least they serve as documentation about what you didn't do initially, so it's more helpful than nothing.)
If there is something that needs to be done and you are not going to do it -- the code is the worst place to put it. Basically, what you are saying is that you have a design in mind and want someone else to finish it. If you really can't trust your coworkers to refactor the code and build good designs on their own, use a different communication mechanism. The better thing is to forget about your long term plans, leave the code as simple as you can and trust your coworkers.
