Best Practices - Human Readable?

Best Practices - Human Readable?
0.0 0

#1

Is best practices for human readability and commenting code followed within industry or ignored?


Uncle Bob's Clean Code for JavaScript
#2

It’s a big industry, so I’d bet both styles are rampant :wink:

There are build tools which strip out comments, white space and rename variables in order to reduce file size in production, which means there is no cost to liberal use of descriptive variable names, comments or white space in your dev files.

Use 'em :slight_smile:


#3

I absolutely hate seeing code on GitHub or wherever that is sloppy, unorganized, and hard to read. By all means you should use line breaks, proper formatting, and comments for confusing sections. And if you are concerned about performance, there are build tools to minimize like Jackson said.

As for industry, a lot of companies have style protocols for how you write software, and you are required to follow if you work for them.


#4

how is the code maintained if it’s stripped clean?


#5

Their local copy isn’t stripped clean.

The best advice I’ve seen for writing comments was in Code Complete. The author suggests writing pseudo-code and then using your pseudo-code as the comments.


#6

Typically you keep a development and production set of your files.

Every time you change dev, you rebuild and get a new prod.

This is what tools like Gulp and Grunt do, among others.


#7

You write the code readable the first time. For example, consider the jQuery code:
https://code.jquery.com/jquery-3.1.1.js
That is what they work on.

Before they deploy they use tools to make a stripped version that looks like this:
https://code.jquery.com/jquery-3.1.1.min.js