Earlier quoted context omitted.
Can you define "over-comment"? Without a clear definition, it's just subjective opinion.
//increment i in for loop For (i=0;i++.... Var x; //define variable x X=4; //give value of 4 to x Everyone knows what that code does. The comments aren't necessary.
Keep your source code SIMPLE
31–40 of 77 posts
Re: Keep your source code SIMPLE
#32Earlier quoted context omitted.
Yes, please comment! I was once on a project where commenting was prohibited presumbely because your code should be self explanatory? Give me a break.
Comments are often a code smell indicating that the code was written in a hard to understand way. On a top notch code base - the kind that almost nobody works on - they probably should be sparse and mostly unnecessary. Moreover, when a lot of people are asked to comment they write stuff like "this function does x to y" when the function is named "x_to_y". No shit sherlock comments I call them. I'd always prefer to ha…
Re: Keep your source code SIMPLE
#33Earlier quoted context omitted.
Comment the why, not the what.
It's good to comment the what too if it's hard to discern what it's doing from the code. There have been a number of cases where, for instance, I had to call a bizarrely named API and do something unexpected in order to get an unintuitive outcome and in that case a "what" comment isn't such a bad idea.
Re: Keep your source code SIMPLE
#34Earlier quoted context omitted.
Is there a language that leans heavily towards immutable data, but steers clear of the, shall we say, dorkier side of functional programming?
This is Clojure. It's functional, but more as a side effect of focusing intently on simple, immutable, persistent data structures and their compositions. I'd strongly recommend looking into it, along with many of the presentations by its initial author Rich Hickey.
I'd say Kotlin over Clojure.
Re: Keep your source code SIMPLE
#35Sorry, can't read behind paywall.
Re: Keep your source code SIMPLE
#36Earlier quoted context omitted.
Yes, please comment! I was once on a project where commenting was prohibited presumbely because your code should be self explanatory? Give me a break.
Comments are often a code smell indicating that the code was written in a hard to understand way. On a top notch code base - the kind that almost nobody works on - they probably should be sparse and mostly unnecessary. Moreover, when a lot of people are asked to comment they write stuff like "this function does x to y" when the function is named "x_to_y". No shit sherlock comments I call them. I'd always prefer to ha…
Re: Keep your source code SIMPLE
#37I couldn’t agree more. Also; keep it clean . Don’t over-comment, but comment.
Yes, please comment! I was once on a project where commenting was prohibited presumbely because your code should be self explanatory? Give me a break.
Writing good readable code is hard, and you don't get it just by banning comments.
Much like how you don't lose weight by buying smaller sized clothes :)
Re: Keep your source code SIMPLE
#38Re: Keep your source code SIMPLE
#39I couldn’t agree more. Also; keep it clean . Don’t over-comment, but comment.
Yes, please comment! I was once on a project where commenting was prohibited presumbely because your code should be self explanatory? Give me a break.
Re: Keep your source code SIMPLE
#40But wait, I want all my code to work in linear space and time, look like assembly code and scale to 4 billion servers.