Comment by YZF | Hacker News Reader

Comment by YZF | Hacker News Reader

Software development is one of those areas where everything has an "it depends" in front of it. If you know what you're doing you don't need generic advice and if you don't it won't help you.

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?

#1 There's nothing wrong with TODO comments. Often you don't want implement feature B in full so that you can focus on feature A. Of course you've told your customers that you'll do both features, so you push feature B back to a future release. No problem in using TODO there - at least you have comments as to what's actually going on and what may need to be fleshed out in the future.

Normally the argument is the this should be part of your backlog and not spread all over the code where no one (and especially the PO) can keep track of all the TODOs in all the files.

Depends on trust. I've had an experience where old tickets documenting important architectural problems (e.g. SQL injection) were mass-closed as "probably obsolete" by managerial types.

I was very happy I left a TODO in the actual code calling out the problem, because I could find and reopen the wrongly-closed ticket.

Heh. Visual Studio actually does keep track of all the TODOs in all the files in your project. It's the Task List window (View -> Other Windows -> Task List, or ctrl-alt-K).

Does it track FIXMEs?

By default it looks for the tokens: HACK, TODO, UNDONE, and NOTE.

However, you can add your own tokens and assign different priorities to them.

https://docs.microsoft.com/en-us/visualstudio/ide/using-the-...

Very nice, it now almost resembles the functionality of "grep -rn FIXME ." in the shell and ":grep -r FIXME ." in vim.

>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)

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".

It is often too obvious that e.g. O((x+y)^2)-drawing will degrade quickly. There is no point in implementing it slow way, because you'll see the effect in few hours and will spend few hours to fix all the places, not mentioning re-architecture cases. 100ms vs. 500ms is non-trivial to predict. O(log(n)) vs. O(n^3) for freely growing n is trivial.

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

For #17 I think he meant more that you shouldn't take code criticism personally. His pithy one liner summary just didn't capture the idea well.

Reply on news.ycombinator.com