What should be the rules to write excellent code?

[pairofstrings]

Hi.

I know few rules that let's me write great code:

1.
"don't pollute the global namespace" when I sit down to write JavaScript code.

2.
SOLID

3.
KISS

4.
Liskov's Open-Closed principle

Can someone help me complete the list of such rules?

Thanks!

Have a great day!

 

[levadny]

I think subject independent from programming language. Minimum, functional and structured programming.

 

[pairofstrings]

I think subject independent from programming language. Minimum, functional and structured programming.

I want to know the big words of programming so that I can look' em up on the internet and study about them.

 

[newjerseyrunner]

Test-driven development.

Code has to be written in such a way that each component of it can be tested independently with only a few lines of setup.

 

[pairofstrings]

Test-driven development.

Code has to be written in such a way that each component of it can be tested independently with only a few lines of setup.

Okay.

 

[jedishrfu]

Functional programming makes life tougher for the programmer but easier for debugging and testing as it eliminates the side-effects of external variables.

https://en.wikipedia.org/wiki/Functional_programming

 

[levadny]

I want to know the big words of programming so that I can look' em up on the internet and study about them.

Ok. Then design patterns and software requirements.

 

[pairofstrings]

Ok. Then design patterns and software requirements.

Wow! Okay. Thanks!

 

[levadny]

More information.

It's best book for software development. For any OOP language. I read only some parts of this book.
https://www.amazon.com/dp/0201633612/?tag=pfamazon01-20

And best book for requirements. It's actually for any activity.
https://www.amazon.com/dp/0735679665/?tag=pfamazon01-20

 

[kolleamm]

Give your variables very detailed and specific names, including iterators such as i, this alone has saved me days of work

 

[phinds]

Documentation

Documentation

Documentation

(And reread post #10)

 

[jim mcnamara]

Steve McConnell 'Code Complete 2' has all of the above and a lot more.

I think @Mark44 can verify that Microsoft had this book on its list of must reads - he was at the Redmond campus for years. I believe. His opinion of the book should count for a lot.

 

[Rive]

Planning, documentation, experience - and an existing codebase to learn from...

 

[Borg]

3.
KISS

Documentation

Documentation

Documentation

(And reread post #10)

100% agree. I would also add that code should be written with two other things in mind.

1. Does your code follow coding and API standards that fall within the guidelines of the project?
2. Will programmers who have to work on your code later be able to understand it? (that includes yourself)

These come from two phrases that I often hear in the coding world that drive me crazy - job security and that will look good on my resume. Neither of these has the customer in mind. Those attitudes usually result in bloated, undocumented software in a language that nobody is familar with resulting in later programmers struggling to understand it and afraid to modify it.

 

[levadny]

What is KISS?

 

[Borg]

Keep It Simple, Stupid

The principle is best exemplified by the story of Johnson handing a team of design engineers a handful of tools, with the challenge that the jet aircraft they were designing must be repairable by an average mechanic in the field under combat conditions with only these tools. Hence, the "stupid" refers to the relationship between the way things break and the sophistication available to repair them.

Which goes back to my original statement about making things so complex and unusual that it can't easily be worked on by those who follow.

 

[Svein]

When I was involved in Software Development, I always insisted on:

1. A design document for the module (written in such a way that if it was inserted as comments in the source code, it would document the code)
2. Do not publish any entry points to the code where you do not want to implement full parameter verification
   
3. As we usually wrote in C: Run the code through lint until lint is satisfied.

 

[Mark44]

Steve McConnell 'Code Complete 2' has all of the above and a lot more.

I think @Mark44 can verify that Microsoft had this book on its list of must reads - he was at the Redmond campus for years. I believe. His opinion of the book should count for a lot.

Anyone who writes code and aspires to be a better programmer should have this book.
It was "Code Complete" at that time (about 2004 or so). Everyone in the Windows Division, about 7500 people, had to take a two-day class on strategies to protect the Windows OS from exploits such as buffer overruns and DOS (denial of service) attacks. Besides the class materials, each person received a copy of McConnell's book, which I still have. I didn't realize that this book is now in a second edition.

 

[newjerseyrunner]

Something I always make sure that I use:

-Wall -pedantic-errors -Werror

It sets the compiler to warn about everything that could possibly go wrong, not let you write non-standard code, and treat all warnings as compiler errors. Even before I go through QA, just setting these flags let's me find all sorts of stupid mistakes. Personally I like everything to be extremely explicit. Method takes a double? Better static_cast<double>() that float!

 

[QuantumQuest]

Think, design, code.
Proper naming of variables, variable scope regarding context at hand, meaningful comments, use of efficient algorithms and efficient implementation and proper documentation are the simplest but unfortunately very often overlooked.
As your experience in programming grows stronger KISS principle changes (i.e. is adapted) accordingly.
Try to leverage the full power of the programming language, IDE, toolchain(s), libraries, frameworks, templates ... (the list goes on) - this also helps in not reinventing the wheel, but adapt and test properly.
When you're about to break some rule(s) justify extensively and if you have to, do it with enough parsimony.

 

[rootone]

Avoid using 'goto' {label} type statements as if they were contaminated with black death pathogens.

 

[levadny]

KISS - it means: let's do all very simple and reliable. Yes?

 

[Mark44]

Avoid using 'goto' {label} type statements as if they were contaminated with black death pathogens.

While I agree this is good advice for beginners, there are legitimate uses for goto's for those who are more advanced. In another thread (https://www.physicsforums.com/threa...number-is-a-prime-number.941151/#post-5951715) I posted the following:

From "Code Complete," by Steve McConnell, p. 348, in a section titled "The Argument for gotos":

The goto is useful in a routine that allocates resources, performs operations on those resources, and then deallocates the resources. With a goto, you can clean up in one section of code. The goto reduces the likelihood of your forgetting to deallocate the resources in each place you detect an error.

In some cases, the goto can result in faster and smaller code. Knuth's 1974 article cited a few cases in which the goto produced a legitimate gain.

Good programming doesn't mean eliminating gotos. Methodical decomposition, refinement, and selection of control structures automatically lead to goto-free programs in most cases. Achieving gotoless code is not the aim, but the outcome, and putting focus on avoiding gotos isn't helpful.

Two decades' worth of research with gotos has failed to demonstrate their harmfulness. In a survey of the literature, B.A. Sheil concluded that unrealitic test conditions, poor data analysis, and inconclusive results failed to support the claim of Shneiderman and others that the number of bugs in code was proportional to the number of gotos (1981)...

In fairness, McConnell also has a section titled "The Argument Against gotos".

 

[rootone]

I agree there are limited situations where they are useful.
For a beginner though they should definitely be avoided because it looks like an easy way of making stuff work.
The resulting code might actually work, but would be difficult for anyone else other than the original coder to make sense of.
Code spaghetti.

 

[anorlunda]

GOTO is an unworthy sidetrack in this thread.

Compsi guru Edsger W. Dijkstra started it; but he complained only about excessive use of GOTO and spaghetti code. An even more luminary compsci guy Donald Knuth wrote "Structured Programming with go to Statements" It is blown out of proportion.

IMO, this thread is about ideas much more important than GOTO.

 

[Mark44]

An even more luminary compsci guy Donald Knuth wrote "Structured Programming with go to Statements"

Here's a working link to the Knuth paper --
http://sbel.wisc.edu/Courses/ME964/Literature/knuthProgramming1974.pdf
The one that anorlunda gave results in a 403 Forbidden HTTP error.

 

[Coelum]

Principle of least astonishment (POLA)

 

[Borg]

Principle of least astonishment (POLA)

Something like this?

 

[NTL2009]

I agree there are limited situations where they are useful.
For a beginner though they should definitely be avoided because it looks like an easy way of making stuff work.
The resulting code might actually work, but would be difficult for anyone else other than the original coder to make sense of.
Code spaghetti.

A GOTO does not necessarily infer spaghetti code. A short jump with a GOTO can make code simpler and easier to read than the logic required to avoid it.

What is a BREAK statement? It is really just A "GOTO the end of this code segment" statement, yet I don't hear people call for the end of the break statement.

Yes, GOTO has been abused, but that does not mean that we need to avoid it, it just means that we should use it properly like any tool.

 

[Coelum]

You may want to have a look at https://www.artima.com/weblogs/viewpost.jsp?thread=331531.