60 Terrible Tips for a C++ Developer
modernescpp.com
modernescpp.com
Again, I'm being asked to just read and execute the code step by step to understand it.
Important parts are uncommented, I don't think there are tests.
Talked about good coding practices on my one month review to make it easier for new employees and the future of the software.
I get that reading the code is what developers should do, but why not help others and make it easier? Even I add comments so that future me can remember how it works.
I remember emitting the idea of building a tool to calculate an opinionated code quality score on irc, I got mocked. If your codebase is low quality either hire people to refactor it or rewrite it.
Bad codebase don't deserve developers in my view.
Thanks for spreading sanity and insight -- I hope someone else digests your message sooner than I did.
Why? If 99% of code bases are bad and it's the baseline condition, why should I try to move things in a better direction?
OP proposed better coding practices and got ignored. OP proposed adding some automated lint checking, etc, and got mocked for it. OP is trying to make things better, and will suffer for it. OP comes to HN and doesn't get any better reception for his ideas either.
I think OP should hold on to his opinions and make sure his resume is up to date.
Code is like entropy: it's natural tendency is to become disordered and not suit the current problem domain.
In order to fight entropy, you need to perform the unnatural act of ordering back and sorting out the code you wrote based on your current understanding of the curremt state of your problem domain.
Also keep in mind that developers continuously gain experience, and gather insight into what works or not, and refine their expertise with time. Your yesterday's code is worse than the code you'd write today. By definition this means that when you look at all the code you wrote, it all needs improving.
> OP proposed better coding practices and got ignored.
He didn't. He proposed wasting time adding comments and dump onto someone else the responsibility of cleaning up his mess. That is not helpful and should be laughed out of the room.
One must wonder what ought to happen with bad codebases
He will eventually, but until now the more experienced people around him will have to be patient.
Comments are a code smell. If the code doesn't make it clear what the application is doing, you need to rewrite it so that it does.
If your project does not have unit tests, that should be your priority. It makes no sense to focus on comments on a project that has no unit tests.
> I remember emitting the idea of building a tool to calculate an opinionated code quality score on irc, I got mocked. If your codebase is low quality either hire people to refactor it or rewrite it.
No. If the code is low quality, it's on you to improve it. It's your personal task.
> Bad codebase don't deserve developers in my view.
The quality of a codebase reflects the quality of the people working on it.
Look at your comment. You're complaining it's low quality and has no unit tests, but what did you brought to the table? A vague comments on adding comments, and complaining that you expect other people should fix it. You're the root cause, not the solution.
The code can only tell you what the application is doing, but sometimes it is also useful to understand why. Were important lessons learned on the way to this particular implementation?
Bad codebases most definitely deserve developers if it makes lots of $.
I recommend reading “How to work with legacy code” on how to do it in practice.