[deleted]
I've never seen a language's style guide recommend avoiding comments before
151–160 of 198 posts
Re: I've never seen a language's style guide recommend avoiding comments before
#152Of course everyone thinks they always write good clean code and therefore don't need comments to elaborate on what the heck is going on. Unfortunately, having been doing this trade for 30+ years, I've found most people write crappy code in a hurry to try to hit some deadline based on incomplete requirements and confusing business rules. A few precious comments stuck in there can help the next guy, months or years lat…
Well that is ... sad. I have not been around for 30+ years and I see good code on a weekly basis. Maybe you should consider changing something in your environment. I assure you it is possible.
Re: I've never seen a language's style guide recommend avoiding comments before
#153how about a language that has no support for comments!?
Re: I've never seen a language's style guide recommend avoiding comments before
#154Earlier quoted context omitted.
Forgive my ignorance, but why and how would you test a comment? They don't do anything, there is no instruction for the machine to understand or run.
Brings up an interesting point about perhaps using natural language processing to determine correctness of a comment. That would be prettty cool.
If you could use NLP to verify the comment, then what would the point of the comment be? Comments are for those aspects of a program that are invisible to the compiler and IDE, the intent.
Re: I've never seen a language's style guide recommend avoiding comments before
#155Earlier quoted context omitted.
Sure, code review is a very manual approach.
Yes, what I mean is, if you're doing code review then there's virtually no additional cost - you're looking over the changes anyway. It doesn't matter that the process is manual if you're already doing it. If you're not doing code review, then you perhaps either have some organisational issues or you have coworkers who are sufficiently responsible that you can trust them to do basic code hygiene work like keeping com…
I think comments would be more difficult to review than code, since you'd have to carefully make sure they are meaningful by examining the code, without the context of the programmers involved. Alternatively, you could add comments during code review to document the review and basically redo the comments on each review...maybe.
Comments also break flow and get in the way of code reading, but could probably just be hidden during review.
Re: I've never seen a language's style guide recommend avoiding comments before
#156Of course everyone thinks they always write good clean code and therefore don't need comments to elaborate on what the heck is going on. Unfortunately, having been doing this trade for 30+ years, I've found most people write crappy code in a hurry to try to hit some deadline based on incomplete requirements and confusing business rules. A few precious comments stuck in there can help the next guy, months or years lat…
Well that is ... sad. I have not been around for 30+ years and I see good code on a weekly basis. Maybe you should consider changing something in your environment. I assure you it is possible.
Maybe he 'sees' bad code that you would consider 'good' code. This can be a bit subjective, and also he has much more experience than you ...
Re: I've never seen a language's style guide recommend avoiding comments before
#157Earlier quoted context omitted.
Often only with a deep understanding of the complex problem to understand its simplicity. But you have to ship in 4 weeks, so why not just get something working first?
> But you have to ship in 4 weeks, so why not just get something working first? Of course, this sometimes happens, but it shouldn't be encouraged. This way you are creating technical debt, which will be very expensive to pay off.
At what point is simple simple enough? You can simplify for a long time just by working at the same problem for a few years. But wow...not everything is a basic crud app.
Re: I've never seen a language's style guide recommend avoiding comments before
#158This style guide is NOT against comments. It is just stating the obvious best practices which have always been around for all languages ...
Re: I've never seen a language's style guide recommend avoiding comments before
#159Earlier quoted context omitted.
Brings up an interesting point about perhaps using natural language processing to determine correctness of a comment. That would be prettty cool.
If you could use NLP to verify the comment, then what would the point of the comment be? Comments are for those aspects of a program that are invisible to the compiler and IDE, the intent.
Maybe my view of NLP is more sci-fi than reality, but I think you're missing what I meant. If you can use NLP to prove that your comment - ie the intent - which IS invisible to the compiler and IDE, then that might be cool. Practical, probably not. But I'd still be very impressed at the implications if this was possible within some error margin.
Re: I've never seen a language's style guide recommend avoiding comments before
#160Good code should be self documenting.
> Good code should be self documenting. Good code needs no test either,... wait no ,that's a stupid thing to say,because nobody writes "good code",code isnt good or bad,it either results in the expected behavior or not.
Depends on how you define "expected behavior".
If it means "the machine executes it and is able to produce the expected outputs with the right inputs", and nothing else, then you are missing a key concept about code.
You see, code is not written for machines. If that was the only reason, we would all write direct binary. Code is written for people. More specifically, other people. (Or you, in the future).
If no one (except a machine) is capable of understanding a piece of code, then that code is indeed bad; it has failed its main purpose. The more understandable by people code is, the better it is.
I agree that once compiled/interpreted, these differences don't matter. Until the next bug or feature request arrives. Then it matters quite a lot.