The 10 major programming maxims that every programmer should know

the 10 major programming maxims that every programmer should know (Kevin Pang):

Programming Maxim 1: Smoke (there is no smoke without fire)
Programming Maxim 2: Prevention, treatment supplement (an ounce of prevention is worth a pound of cure:)
Programming Maxim 3: Don't put all your eggs in one basket (Don ' t put all your eggs in a basket)
Programming Maxim 4: Man sows, reap (as you sow,so Shoul you reap)
Programming Maxim 5: Haste to waste (great haste makes great waste)
Programming Maxim 6: Think twice (look before you leap. Think First, program later)
Programming Maxim 7: When your only tool is a hammer, everything looks like a nail (when the just tools you had is a hammer, everything looks likes a nail)
Programming Maxim 8: Silence is approval (silence is construed as approval)
Programming Maxim 9: Two birds in the forest is not a bird in the hand (A bird in the hand is worth, the bush)
Programming Maxim 10: The greater the capacity the greater the responsibility (with great power comes great responsibility)
1. Smoke (there is no smoke without fire):
Poorly designed code typically shows some of the following phenomena:
A huge class or method
Code for large block annotations
Repetitive logic
Too many levels of if/else nesting

Poorly designed code tends to manifest itself through some common tell-tale signs. Some examples of these are:
Giant classes and/or functions
Large blocks of commented out code
Duplicated logic
Deeply nested if/else blocks
Developers often refer to these as code smells, but personally, I think the term "code smoke" or "code fumes" was more appr Opriate as it implies a higher sense of urgency. If you don ' t address the underlying problem it'll come back to burn you later on.
2. Prevention, treatment supplemented (an ounce of prevention is worth a pound of cure) Ax
Programmers often mistakenly think that high-efficiency coding is fast coding, and many programmers write code directly without thinking and designing. Unfortunately, this Leeroy Jenkins reckless approach will write the code of the cake, resulting in the need to constantly maintain and modify the code, and even possibly the code of these cakes will be replaced. Therefore, the encoding efficiency is not only in the time of encoding, but also in the time of debugging code.
Penny Wise lost the watermelon. Ax
Original:

Toyota's assembly line of the 1980s is famously efficient due to its revolutionary approach towards defect prevention. Each member of the assembly line is given the ability to halt production when they noticed a problem in their sector. The idea is that it is better to halt production and fix the problem as early in as possible than to continue producing Faulty units that would is tougher and more costly to fix/replace/recall later on.
Developers often make the faulty assumption this productivity = cranking out code quickly. Many programmers dive straight into coding without a second thought towards design. Unfortunately, this Leeroy Jenkins approach towards software development tends to leads to sloppy, fragile code that would n Eed to is constantly monitored and patched-perhaps even replaced altogether down the line. Ultimately, productivity must be measured isn't only on how much time was spent writing it, but also by what much time is Spen t debugging it. A short term gain could prove to is a long term loss if one isn ' t careful.
3. Do not put all eggs in a basket (Don ' t put all your eggs in one basket) do not rely too much on someone
A common element of a software project development team (bus factor) is the total number of core developers who will affect the overall project process. For example, if someone gets hit by a car or a child or someone is on the job, the project may be out of order or even put on hold.
In other words, what happens to the project if the key members of the team are suddenly lost? Will the business continue or cease?

Therefore, in project development, it is best for each developer to be familiar with the parts of the software system that are not what they are good at.

Original:

A Software team ' s bus factor is defined as "the total number of key developers who would if incapacitated, as by getting H It by a bus, send the project into such disarray that it would is not being able to proceed ".
In the other words, what happens if you suddenly lost a key member of the Your team? Would business continue as usual or would it grind to a halt?
Unfortunately, most software teams fall into the latter category. These is the teams that turn their programmers to "domain experts" who only deal with requests, fall into their is A of expertise. At first, this appears to be a fairly reasonable approach. It works for the automaking assembly lines, why isn't for software development teams? After all, it's unreasonable to expect each member of the team to being intimately familiar with each and every nuance in the Application, right?
The problem is this developers cannot be easily substituted and replaced. And while the pidgeon-hole approach works fairly well when everybody are available and accounted for, it quickly falls Apar t when the "domain experts" suddenly become unavailable due to turnover, sickness, or even freak bus accidents. It's imperative that software teams has some sort of redundancy built in. Code reviews, pair programming, and communal code go a long foster an environment where each developer are at least Superficially familiar with parts of the system outside their comfort zone.
4. Man sows, reap (as you sow, so shall you reap)
In the book "Pragmatic Programmers," there is a passage explaining the "broken Window Theory":

Don't keep the "broken windows" (bad design, bad decisions or bad code) from being repaired. Find one and fix one. If you don't have enough time to fix it properly, keep it up first. Perhaps you can put the offending code in a comment, or display an "not implemented" message, or replace it with virtual data. Take some measures to prevent further deterioration. This shows that the situation is still under control.

We've seen a neat and tidy system crash immediately after the "broken Window" appears. While there are other factors that drive software crashes (which we will be exposed to elsewhere), ignoring the "broken window" will definitely speed up the system crash faster.

In short, good code can lead to good code, and bad code can lead to bad code. Don't underestimate the power of habit. No one wants to tidy up bad code, and no one wants to mess up the perfect code. Write your code and it will be more likely to withstand the test of time.

Original:

The pragmatic Programmer have this to say about the broken Window theory:
Don ' t leave "broken windows" (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If There is insufficient time-to-fix it properly, then board it up. Perhaps you can comment out the offending code, or display a "not implemented" message, or substitute dummy data instead. Take some action to prevent further damage, and to show this you ' re on top of the situation.
We ' ve seen clean, functional systems deteriorate pretty quickly once Windows start breaking. There is other factors the can contribute to software rot, and we'll touch on some of them elsewhere, but neglect Accele Rates the rot faster than any other factor.
In short, good code begets good code and bad code begets bad code. Do not underestimate the power of inertia. No one wants to is the one who have to clean up sloppy code, but neither does anyone want to being the one that makes a mess o UT of beautiful code. Write it right and your code would has a far better chance at standing the test of time.
5. Haste to waste (great haste makes great waste)
Managers, customers and programmers are becoming increasingly impatient. Everything needs to be done, need to do it right away. Because of this, quick fix issues become very urgent.

No time for proper unit testing of a new feature? Well, you can finish the test run first and then you can go back and test it at any time.

When accessing the Y property, will you encounter strange object reference errors? In any case, put the code in the Try/catch statement block. We're going to catch the big fish!

Is it familiar? This is because we have done it before. And in some cases, it is beyond reproach. After all, we have deadlines, and we have to meet our customers and managers. But don't operate too often, or you'll find your code unstable, with lots of hot fixes, logical duplicates, non-tested scenarios, and error handling. In the end, you either get things done hastily or get things done well.

Original:
Managers, clients, and programmers is getting more impatient by the day. Everything needs to is done and it needs to is done now. Because of this, the temptation-to-throw together hacks and quick-fixes becomes very tough to resist.
No time to properly unit test a new feature? Oh Well, it works for the one test run you put it through. You can always come back to it later!
Mysterious object referencing error when do I try to access property Y? Whatever, just throw a try/catch block around the code. We ' ve got bigger fish to fry!
Sound familiar? It's because we ' ve all done it at some point in time. And in certain instances, it's justifiable. After all, we had deadlines to meet and clients/managers to satisfy. But does it too often and you'll soon find yourself with a very unstable code base full of hotfixes, duplicated logic, untes Ted Solutions, and porous error handling. In the end, you had to strike a balance between getting things done and getting things do right.
6. Think twice (look before you leap)
The term "agile development" has been frequently abused recently and is often used by programmers to disguise their poor planning/design phases in software development. We are the designers, we should be happy to see that the product has made substantial progress in the proper direction. But unexpectedly, UML diagrams and use case analysis do not seem to satisfy our wishes. So, when you don't know what you're doing or don't know where you are, our developers often write code in a muddle.

It's like you're going to eat, but you don't even think about where to eat. Because you are so hungry, you can't wait to find a restaurant and set up a table. Then you get in the car and you think (find a place to eat) along the way. It's just that it takes more time, because you're going to have more U-shaped corners and parking in front of the restaurant, and maybe the last time you wait is too long to eat. To be exact, you should finally be able to find a place to eat, but you may not be eating the food you want, and it may take longer than you would have to order at the restaurant you want to go to.

Original:

The term "Agile development" was used and abused frequently these days, often as a-to-programmers to justify ignoring The dreaded planning/designing phase of software development. We is creators, and as such we derive pleasure from seeing actual progress made towards a finished product. Surprisingly, UML diagrams and use case analysis just don ' t seem to satisfy that desire. So, we developers often start off coding without any idea of the what we is doing or where we are going. It's like the heading out for dinner when you haven ' t yet decided where you are want to go. You're hungry so you don ' t want to waste time finding a restaurant and booking a table. Instead, you just hop in your car and figure you ' ll think of something along the. Only, the IT ends up taking you longer because a bunch of U-turns and stops at restaurants Too long of a wait. True, you'll probably find your the eventually, but you probably didn ' t end up with the meal you wanted and It probably took a lot more time and hassle than it would has had you just called and booked a reservation at a Restaura NT wanted to go.
7. When one of your tools is a hammer, everything looks like a nail (when the Just tool is a hammer, everything looks likes a nail)
You see that? I already told you, dynamic records are very effective in this project.
Programmers have a tendency to narrow their horizons when it comes to their tools. Once a method "makes sense" on one of our projects, we will use it on all the projects that follow. Learning new things seems to be a torment, sometimes even uneasy. From start to finish thinking, "If I did it the way I did it, it wouldn't be so much trouble." Be sure to abandon this idea and do as we know it, even if it's not the perfect solution.
It's easy to stick to what you know, but in the long run it's much easier to choose a tool that fits the job. Otherwise, it will be incompatible with your career.
）
Original:

See? I *told* you Active Record would work for this project!
Programmers has a tendency to get tunnel vision when it comes to their tools. Once something "just works" for us on one project, we tend to insist on using it for every project Therafter. It can be a pain-learn something new and, at times, highly unsettling. The entire time we ' re thinking "it would has been easier had I just done it's the old way!". Enough of these moments and we'll simply go with what we know, even if it isn ' t a perfect fit for the task.
It's easy-to-stick with what's know, but the long run it's much easier to pick the right tools for the job. Otherwise you'll be fitting square pegs to round holes for the rest of your career.
8. Silence is approval (silence is construed as approval)
I didn't see anything! I didn't see it!

"Broken Window Theory" and "become inertia theory" has a macroscopic connection.

The programming community is like a real community. Each work is a microcosm of a developer. The more bad code is published, the easier it is to reflect the status quo. If you don't work hard to write good, neat, and stable code, you'll be with bad code every day.

Similarly, if you see someone writing bad code, you're going to have to ask that person. Note that wit should be on the pitch at this time. In general, programmers are willing to admit that they do not understand the software development, and will thank you for your kindness. Helping each other is good for everyone and turning a blind eye to the problem will only make the problem persist.

Original:

I See nothing! nuh-thing!
This ties in with the theory on broken windows and programming inertia, only on a larger scale.
The programming community is just, a community. Each programmer are a reflection on the craft. The more bad code which is released to the wild, the more it becomes the status quo. If you do a effort to write good, clean,solid code, you'll find yourself have to work with it on a day-to-day Basis.
Likewise, if you see poorly designed code written by someone else, you should make the effort to bring it up with the Crea Tor. I should note, however, that tact ought to being employed in such a situation. In general, programmers was willing to admit that they does not know everything there was to know about software development And would appreciate the gesture. We all benefit if we help each of the other out. Turning a blind eye to problems only perpetuates them.
9. Two birds in the forest is not a bird in the hand (A bird in the hand is worth, the bush)
If you can talk about system architecture and refactoring, then find a time to get things done. It is important to weigh the pros and cons of the changes in order to make things simpler and easier to work with. Of course, brevity is an ideal goal, but there will always be code that can be improved by refactoring. In the programming world, code changes frequently and easily for code. But sometimes you have to make sure that the code is valuable to the customer. So, you face a simple dilemma: you can't stone. The more time you have to refactor the old code, the less time you will have to write the new code. There is also a need to find a balance between improving code and maintaining programs in a timely manner.
Original:
There is a time and place to discuss system architecture and refactoring opportunities, and a time to just get things done . It's important to weigh the pros and cons of revamping something, already works just to make it cleaner. It's an admirable goal, of course, but there'll always be code that's want to restructure. The programming world simply changes too frequently for code to not get outdated. But at some point, you had to provide the value to your customers. The simple fact remains:you can ' t does the things at once. The more time is spend refactoring old code and the less time you spend creating new code. Striking a balance is critical to enhancing as well as maintaining your application in a timely manner.

10. Greater capacity responsibility (with great power comes great responsibility)
There is no doubt that software has become a fundamental and important part of our lives. Because of this, developing excellent software is especially important. The bug in table tennis is one thing, the bug in the shuttle guidance system or the air traffic control system is another matter. Slashdot once published a story about a small mistake in Google News alone that evaporated a company's stock by $1.14 billion. For other examples, see the 10 serious consequences of a software bug. These examples illustrate how much power we are exercising. The code you write today, whether you want it or not, might someday come in handy in important applications, which is frightening. Write properly qualified code!
Original:

Software has undoubtedly become a integral and vital part of our lives. Because of this, practicing good software development are more crucial than ever. It's one thing to has a bug in a game of Pong, it's another to having one in the guidance system of a space shuttle or air Traffic control system. Slashdot recently posted an article describing what a minor glitch in Google News singlehandedly evaporated $1.14 billion I N Shareholder Wealth. Events such as these demonstrate how much power we wield. It's a little frightening to think so the code you write today, whether your intend it to or not, could one day be recycled and depended upon for mission-critical applications. Write accordingly.
Does you have any proverbs feel should is added to this list? Feel free to let me know in the comments!

The 10 major programming maxims that every programmer should know