Live data from Hacker News

Keep your source code SIMPLE

medium.com

21–30 of 77 posts

Re: Keep your source code SIMPLE

#21
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?

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.

Re: Keep your source code SIMPLE

#22
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?

Elm.

Re: Keep your source code SIMPLE

#23
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.

I've seen code in which the development team added a revision comment in the source file for every revision to the source file, instead of just letting the version control system handle it.

Re: Keep your source code SIMPLE

#24
post #6

Earlier quoted context omitted.

(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 le…

[deleted]

Re: Keep your source code SIMPLE

#25
post #3

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.

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

Re: Keep your source code SIMPLE

#26
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?

In my opinion Erlang (and by extension Elixir) are functional-ish languages that are at their core very pragmatic about not being too _dorky_.

Re: Keep your source code SIMPLE

#27
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?

Haskell.

Re: Keep your source code SIMPLE

#28
post #12
post #2

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

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 have good comments, but I've worked on a lot of code bases where no comments wouldn't really have been any worse.

Re: Keep your source code SIMPLE

#29

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.

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

It can provide an incremental improvement but it is https://en.wikipedia.org/wiki/No_Silver_Bullet

Re: Keep your source code SIMPLE

#30
post #2

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

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.

Post reply on HN