Live data from Hacker News

Keep your source code SIMPLE

medium.com

51–60 of 77 posts

Re: Keep your source code SIMPLE

#51

Earlier quoted context omitted.

I'm not sure what you mean. Comments are for explaining code that IS there.

comments shouldn't explain code period; they are to clarify intent.

Comments are there to clarify whatever is not easily understood in the code. If that's intent, sure, it's intent that should be commented.

It's not always the intent that needs clarification.

Re: Keep your source code SIMPLE

#52
post #3
post #2

I couldn’t agree more. Also; keep it clean . Don’t over-comment, but comment.

Can you define "over-comment"? Without a clear definition, it's just subjective opinion.

JSDoc. It's a fucking tragedy on code bases.

I've seen it happen many times now. A nice, clean, easy-to-read code base turns into a forest of unreadable shit thanks to the introduction of parsed comment tags. Perl, Ruby, Python, JS. Doesn't matter what tool or language.

Please, people. I beg you. Stop putting this shit in code. Not everyone is using the same bloated IDE as you, nor do we care to maintain your silly block text and parameter text that is outdated the day you wrote it. If your function needs a block text to explain how to use it, you need to find a new job. I'm serious. You're not good at your job. If it's not self-evident what the file you're looking at does and the function within the file does, then refactor it. Cut it down. Make it make sense.

Re: Keep your source code SIMPLE

#53
post #5

Earlier quoted context omitted.

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.

over-commenting is explaining in pseudo-english what you've written in code. Prentend you are at the United Nations but you speak all the langauges, so you don't need a word-for-word translation. You don't understand to motivations of every speaker though, nor their cultural influences and a million other factors, so context is super important. In the briefings you get some of the information is not new; but if the vast majority of what you're told is obvious or discernable from what people say, you're looking at over commenting. It's not a yes-no thing but a balance of evidence, subjective opinion.

Re: Keep your source code SIMPLE

#54
post #15

My 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?

Kotlin for me. Val is immutable and they differentiate collections, i.e. list vs mutableList. This is still hampered by the JVM but it works.

Combine that with multi platform productivity. If you do want to get dorkier there are fully functional libraries.

Re: Keep your source code SIMPLE

#55
post #15

Earlier 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?

What is 'dorky' WRT functional programming?

Offhand, I’d say “too much theoretical math in the starting and middle stages of mastering the language.” Syntax that is based around/descended from APL. Lambda calculus prominently featured in the learning process. Things like that.

It’s definitely a feel argument, and thus highly subjective.

Re: Keep your source code SIMPLE

#56
post #20
post #15

Earlier 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?

JS with React is great if you use an immutable data structures library and compose functions.

ES6 and newer JS is a great functional language.

That said, I do not recommend immutable libraries. Here are the reasons:

1. They provide false comfort. Nothing in JS is truly immutable. People are just going to end up breaking the rules (purposely or inadvertently).

2. Boxing and unboxing regular JS objects becomes a pain in the ass and a maintenance horror show. You'll never know what an object is and you'll have to jump through countless hoops to get plain old JS objects to do anything with anyway.

Much better is to educate developers, and make sure code is properly reviewed before merging. Immutability doesn't need to be built into the language. Code customs and practices can go a long way.

Re: Keep your source code SIMPLE

#57
post #15

My 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?

Scala / Dotty, or its smaller brothers like Kotlin or Swift

Re: Keep your source code SIMPLE

#58

Earlier quoted context omitted.

//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.

And, strangely, it's the only response to the gp's request to define of over-commenting, yet it is downvoted to below definitions of good commenting.

So. Weird. The other responses didn't properly implement the requirement specification.

I am so confused.

Re: Keep your source code SIMPLE

#59

Earlier quoted context omitted.

//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.

This is what I’m saying by over-commenting. I stated comments at the beginning of functions - what are the arguments? - what does it return - or at the beginning of class names are the wise go.

Yes it's an example of over commenting, which is exactly what the gp wanted.

Re: Keep your source code SIMPLE

#60
post #25

Earlier quoted context omitted.

//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.

This is instructive to new coders, on how NOT to comment.

That's what was asked for! Why on earth is the comment that properly delivers the expectation being discussed as though it's wrong?
Post reply on HN