Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@Avyy if you feel there is some arcane reason for leaving In commented code, I expect an accompanying comment that is at least 2 sentences long about why it’s there.
-
@Avyy well, for example there are debug comments that are not always useful. They fill the cli for no freaking reason. I'll leave in logging statements for bottleneck areas, (maybe even set a flag for it) for example, but just comment them out. It doesn't take a genius to discover what it's useful for. Otherwise sometimes it's actually functional code. (Left there with a comment, cuz chances are I won't be able to remember what it's useful for in a week) Even with git, big projects are hard to find shit in, so important stuff should be accessible.
I think aiming for pretty files instead of functionality and maintainability is the definition of unprofessionalism.
1) Read the wiki on git. I probably have enough shorthands and test methods that you won't need much other shit to debug issues.
2) when debugging, remember that if it is there, there's a good reason why I put it there.
3) commented-out code is probably useful for maintenance. I left it there for a good reason. 😛
4) chances are whatever I wrote, was the state of the art at the time I wrote it. There might be better ways to do it now tho.
5) I always work modular. First, understand the structure. (probably also documented on wiki) DO NOT fuck up the structure. If you change it, you document it.
6) If you feel I wrote shit, it's probably because management annoyed the living shit out of me. Pun intended.
7) Your confusion is normal. I don't do dumb shit.
rant
wk288
dear next dev