But wait, I want all my code to work in linear space and time, look like assembly code and scale to 4 billion servers.
Keep your source code SIMPLE
11–20 of 77 posts
Re: Keep your source code SIMPLE
#12I 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
#13Earlier quoted context omitted.
Can you define "over-comment"? Without a clear definition, it's just subjective opinion.
Sure! The beginnings of functions, for instance, are great places to comment, perhaps even including a definition of some of the subroutines within it. In the case of an exceptionally large subroutine, commenting within the subroutine may be advantageous - but at that point you may consider another function to replace that larger chunk. Variable names that are perhaps obscure and are not practical to rename for whate…
You didn't really answer my question though. I didn't ask where you should comment. I asked for an objective definition of what over-commenting would be.
Re: Keep your source code SIMPLE
#14I couldn’t agree more. Also; keep it clean . Don’t over-comment, but comment.
If you can't give clear advice on commenting, please don't give such advice.
Re: Keep your source code SIMPLE
#15My feeling is these paradigms, SOLID and SIMPLE, boil down to basically: small objects, connected minimally, though interfaces. SIMPLE appears to be leaning even more towards the functional programming side of things; I think we should probably just get it over with and accept that composition of functions operating on immutable data structures is just the right way to go.
Is there a language that leans heavily towards immutable data, but steers clear of the, shall we say, dorkier side of functional programming?
Re: Keep your source code SIMPLE
#16Earlier quoted context omitted.
Can you define "over-comment"? Without a clear definition, it's just subjective opinion.
(not OP, but here's my 2c) comments should explain why you choose to write the corresponding line of code. It's a "meta-communication" between the original author (even a previous-month you) and the reader. Code reading should be "boring". The code lines (and so the meaning) should be obvious. A good comment, IMHO, should convey the information "I'm sorry for this complexity here, but you need to take care of this ed…
That's a reasonable attempt at defining what over-commenting is by trying to define what it isn't. However, it's not a very subjective definition. I tend to write fairly long comments anywhere I think it might help me in the future. I can't predict what I'll forget. I can't predict what will help me understand my code in the future. I have almost never looked at a comment and wished that someone would have written less (aside from comments that just mimic the code, e.g. "increment x"). It's almost always the opposite. I almost always wish I (or the other dev) had left more information.
Literate programming comes to mind as an extreme counter example of not enough comments. https://en.wikipedia.org/wiki/Donald_Knuth#Literate_programm...
Re: Keep your source code SIMPLE
#17Earlier 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.
That's a good concrete example of bad comments. I suppose you could throw that in the "over-commenting" category.
Re: Keep your source code SIMPLE
#18My feeling is these paradigms, SOLID and SIMPLE, boil down to basically: small objects, connected minimally, though interfaces. SIMPLE appears to be leaning even more towards the functional programming side of things; I think we should probably just get it over with and accept that composition of functions operating on immutable data structures is just the right way to go.
Is there a language that leans heavily towards immutable data, but steers clear of the, shall we say, dorkier side of functional programming?
Julia is pretty good at this. Immutability is the default with functional composition. It is primarily intended for numerics though.
Re: Keep your source code SIMPLE
#19My feeling is these paradigms, SOLID and SIMPLE, boil down to basically: small objects, connected minimally, though interfaces. SIMPLE appears to be leaning even more towards the functional programming side of things; I think we should probably just get it over with and accept that composition of functions operating on immutable data structures is just the right way to go.
Is there a language that leans heavily towards immutable data, but steers clear of the, shall we say, dorkier side of functional programming?
Swift.
Re: Keep your source code SIMPLE
#20My feeling is these paradigms, SOLID and SIMPLE, boil down to basically: small objects, connected minimally, though interfaces. SIMPLE appears to be leaning even more towards the functional programming side of things; I think we should probably just get it over with and accept that composition of functions operating on immutable data structures is just the right way to go.
Is there a language that leans heavily towards immutable data, but steers clear of the, shall we say, dorkier side of functional programming?
JS with React is great if you use an immutable data structures library and compose functions.