To me, FIX implies that something is wrong, not that it works but could use improvement.

I would like to have a tag for "here's something that works, but could be improved" though!

Pray tell, what line would you NOT put that tag on? That's like, all code...

TODO is for when you know something specific that can be improved and want to document it, not just generally that nothing is perfect.

I occasionally get to write code that is as good as I think it can be. That doesn’t mean it’s perfect, but I don’t know how to improve it.

Something I've seen Jonathan Blow do that I like is tag things // @Speed when doing a quick to type but slow to run kind of first pass.

It seems nice to have tags for places to jump where the improvements are obvious, rather than hoping to just remember/spot them later.

I think we all occasionally write code we like, but I also write code I don't like, but only the most vague idea on how to improve.

I similarly don't want to brag about my skills in pointing out areas of improvement in code that others might think is optimal, so I won't answer that.

Isn't that what NOTE is for? The code is fine for now, but here are some constrains/limitations/implementation details that you should know when you want to touch that par of the code.

That seems like a good compromise. I've used LOOKAT to note places where I got things going but felt like there was a better way of doing things if I had more time.

Is there a standard for valid flags? I recently recommended a client use `TODOSECURITY` for todos which had security implications until fixed - I discovered functionality which was implemented before authorisation had been developed, resulting in a codepath which was unintentionally reachable by standard users.

Seemed weird to make up a codeword but I wasn't aware of any standard convention, and visually highlighting high impact issues (w/ the bonus of greppability) seemed like a sane approach in rapid development environments.

Open a ticket for that straight away and start working on it immediately. Or 3 years later. Whichever actually happens.

Yeah, that's probably true. I don't have any visibility over that particular projects ticketing system but I imagine it was never raised given it wasn't fixed until I noticed it.

I’d strongly recommend not landing code that has known security problems.

It was my job to look for security problems.