Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Keep your source code SIMPLE

medium.com

Post reply on HN
Print view View original

1–10 of 77 posts

Re: Keep your source code SIMPLE

#4

Post by hinkley »

Complexity is combinatorial. If you compose your code of overly complex components the end result will have much more emergent behavior.

If everything at the bottom is straightforward, then people will spot more overarching concerns, instead of bogging down in minor details.

I’d really love to see some cognitive science applied directly to UX and code quality concepts. Surely some of the things we espouse but don’t enforce are spot on, and others are cargo culting. Refining that list might make it harder to ignore.

Re: Keep your source code SIMPLE

#5

Post by lostgame »

tchaffee wrote: post #3
lostgame wrote: 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.

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 whatever reason can also use comments.

Class headers are of course also a great place to comment, to explain the purpose of the class.

Good comments can lead to better code. :)

Re: Keep your source code SIMPLE

#6

Post by _ZeD_ »

tchaffee wrote: post #3
lostgame wrote: 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.

(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 edge case..."

Re: Keep your source code SIMPLE

#7

Post by throwaway35784 »

tchaffee wrote: post #3
lostgame wrote: 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.

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

Re: Keep your source code SIMPLE

#8

Post by taberiand »

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.

Re: Keep your source code SIMPLE

#9

Post by thinkpad20 »

> Error: ENOENT, no such file or directory '~/foorc'

I can’t count how many times I’ve seen error messages that look like this, often with no context at all, in JavaScript apps, even widely used ones like npm and webpack. Proper error handling is never easy, but the JS community seems particularly given to avoiding it.

Post reply on HN