3 ms·

≥ Especially when the change appears to be trivial on the surface Comments about the code should be in the code, where the next dev will see it. The more trivi

≥ Especially when the change appears to be trivial on the surface Comments about the code should be in the code, where the next dev will see it. The more trivial a change, with far- reaching implications, the more important this is. Doing so has heaps of benefits: future devs understand ramifications, shows that this code has been scrutinized, makes it easier when doing refactoring /yanking, or porting code. That said, leaving the life story out will always be a good idea.

schnable 7y ago
Agreed, but in this case, it was an encoding/whitespace change so there isn't really anywhere else to put this info.
bluedino 7y ago
IMO the repo is the code However, I would have done a simpler commit and linked to an issue where I explained the problem/solution in more detail
- mark-r 7y ago
  This assumes your issue tracker doesn't change. I've been at my current position 8 years, and in that time we've had 3, and the first 2 are shut down.
  - bluedino 7y ago
    We use Gitlab so it has both in the same project - but like you said that could change