What does a good programmer code look like?

Question

I am a hobby programmer (started with VBA to make excel faster) and worked with VB.NET/C#.NET and I am trying to learn ADO.NET.

The aspect of programming that has always upset me is what looks “good”? I am not a professional, so I have nothing to compare. What makes a better programmer? It:

• Do they better understand all objects / classes / methods in a given language?
• Are their programs more effective?
• The design of their programs is much better in terms of better documentation, a good choice of names for functions, etc.

In other words, if I looked at the code of a professional programmer, what is the first thing I would notice about my code relative to mine? For example, I read books like Wrox press's "Professional ASP.NET". Are the code examples in this book "world class"? Is this the top? Will some top gun programmer look at this code and think it's good code?

Answer 1

The list below is not exhaustive, but it is what I thought about when considering your question.

• Good code is well organized. The data and operations in the classes are the same. There are no extraneous dependencies between classes. This is not like spaghetti.

• Good comments on the code explain why not what is done is done. The code itself explains what has been done. The need for comments should be minimal.

• Good code uses meaningful naming conventions for all but the most transitory objects. the name of something is informative about when and how to use the object.

• Good code is well tested. Tests serve as an executable code specification and examples of its use.

• Good code is not smart. It makes things simple, obvious ways.

• Good code is designed in small, easy-to-read units of calculation. These units are reused throughout the code.

I have not read it yet, but the book I plan to read on this topic is Clean Code by Robert C. Martin.

Answer 2

The first thing you noticed is that their code follows a sequential coding code . They always write down their structural blocks in the same way, indent religiously and, if necessary, comment.

The second thing you noticed is that their code is segmented into small methods / functions that span no more than a couple dozen lines. They also use self-describing method names and, as a rule, their code is very readable.

The third thing you noticed after you messed up a bit with the code is that the logic is easy to track, easy to modify, and therefore easy to maintain.

After that, you will need some knowledge and experience in software development methods to understand the specific options that they used to build their code architecture.

As for books, I have not seen many books where the code could be called a "world class". In books, they try mainly to present simple examples that may be relevant to solving very simple problems, but do not reflect more complex situations.

Answer 3

Fowler quote summarizing readability:

Any fool can write code that a computer can understand.
Good programmers write code that people can understand.

'said.

Answer 4

Personally, I will have to quote Tim Peters "Zen Python." He tells Python programmers what their code looks like, but I found that it applies to the main code.

Beautiful is better than ugly.
Explicitly better than implicit.
Simple is better than complex.
The complex is better than complex.
Flat is better than nested.
Rare is better than dense.
Readability indicators.
Special cases are not complicated enough to break the rules.
Although practicality beats purity.
Mistakes should never pass silently.
If clearly hushed up.
In the face of ambiguity, give up the temptation to guess. There should be one — and preferably only one — the obvious way to do this.
Although this method may not be obvious at first, if you are not Dutch.
Now better than never.
Although it’s never better than now.
If the implementation is hard to explain, this is a bad idea.
If the implementation is easy to explain, this might be a good idea.
Namespaces are one good idea - let me do more!

Answer 5

Code is poetry.

Start at this point in logic, and you can get many of the desired qualities of the code. Most importantly, note that the code reads much more than it is written, so write code for the reader. Rewrite, rename, edit and refactor for the reader.

A follows from the corollary:

The reader will be at time n from the date the code was created. Paying the written code to the reader is a monotonously increasing function of n. The reader who is looking at your code for the first time is n == infinite.

In other words, the longer the time span from the moment you wrote the code when you revised the code, the more you would appreciate your efforts to write for the reader. In addition, anyone you separate from your code will benefit greatly from code written by the reader as a primary consideration.

Second Corollary:

Code written without the reader in mind can be unnecessarily difficult to understand or use. When consideration for the reader falls below a certain threshold, the reader receives less value from the code than the value obtained by rewriting the code. When this happens, the previous code is discarded and, tragically, a lot of work is repeated during rewriting.

The third consequence:

It is known that two testimonies are repeated several times in a vicious cycle of poorly documented code, followed by forced rewrites.

Answer 6

I have been programming for 28 years and I find this difficult question to answer. For me, good code is a complete package. The code is written cleanly, with meaningful variable and method names. It has good comments that comment on the intent of the code and not just disrupt code that you can already read. The code does what it should use efficiently without wasting resources. It should also be written with a view to maintainability.

The bottom line is that these are different things for different people. What I could call good code, someone might hate. Good code will have some things in common, which I think I defined above.

The best you can do is expose yourself. Look at other people's code. Good source for this are open source projects. You will find good code and bad code. The more you look at it, the better you will know what you define as good code and bad code.

Ultimately, you will be your judge. When you find the styles and techniques that you like, you will come up with your own style over time and change over time. There is no person who can wave his wand and say what is good and that something else is bad.

Answer 7

Read the book Code Completed. This explains a lot of ideas on how to structure the code and the reasons for this. Reading it, you should short-circuit your time in order to get the experience necessary for a good perception.

http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=pd_bbs_sr_1?ie=UTF8& S = books & QID = 1229267173 & cp = 8-1

Answer 8

Having been programming for almost 10 years and working with others myself, I can say without prejudice that there is no difference between a good programmer and the average code of programmers

All programmers at a competent level:

• Comment is correct
• Effective structure
• Clear document

I once heard an employee say: "I have always been very logical and rational. I think I like to develop."

This, in my opinion, is the mind of a smart programmer. Someone who sees the world in terms of rules and logic and ultimately obeys these rules when developing and writing a program.

An expert programmer who understands the rules, but also their context. This ultimately leads to the fact that they come up with new ideas and implementations, a sign of an expert programmer. Programming is ultimately an art form.

Answer 9

In short, one can read and understand good programmer code.

In my opinion, a good programmer code is an agnostic language ; well-written code can be read and understood in a short period of time with minimal thinking, regardless of the programming language used. Whether the code is in Java, Python, C ++ or Haskell, well-written code is understood by people who don’t even program in that particular language.

Some characteristics of the code that are easy to read are well-known methods, lack of "tricks" and confusing "optimization", classes are well designed to name a few. As others have noted, the coding style is consistent, concise, and straightforward .

For example, the other day I looked at TinyMCE code to answer one of the questions about stack overflow. This is written in JavaScript, a language that I barely used. However, due to the coding style and comments that are included, along with the structuring of the code itself, this was pretty clear, and after a couple of minutes I was able to navigate through the code.

One book that was perfectly clear to me for to read good programmer code, - Beautiful code . There are many articles written by the authors of various software projects in different programming languages. However, when I read it, I realized that the author wrote in his code, despite the fact that I did not even program in this specific language.

Perhaps we should remember that programming is also associated with communication not only with the computer, but also with people , so a good programmer code is almost like a well-written book that can communicate to the reader about the ideas he wants to convey.

Answer 10

• Easy to read
• easy to write
• easy to maintain

everything else is filigree

Answer 11

Good code should be easy to understand. This should be well commented.
Complex details should be commented even better.

Answer 12

Good code is readable. You can easily understand what the code does when you first read the code, written by a good professional programmer.

Answer 13

Instead of repeating all the other great sentences, I suggest you read the Code Complete book by Steve McConnell instead

In fact, this is a book filled with advanced programming technologies for both functionality and style.

Answer 14

I just wanted to add my 2 cents ... comments to your code - and the code itself, as a rule, should say what your code does, now how it does it. When you have the concept of "client" code, which is code that calls another code (the simplest example is the code that calls the method), you should always worry more about making your code understandable from the point of view of the "client". As your code grows, you will see that it is ... uh, good.

Many other things regarding good code relate to the mental leaps you take (definitely, if you pay attention) ... 99% of them have to do a bit more work, to save you tons of work later and reuse . And also with the right things: I almost always want to use a different way, and not use regular expressions, but every time I enter them, I understand why everyone uses them in all the languages ​​I work for (they are abstruse, but work and probably couldn't be better).

As for looking at books, I would say that it is definitely not in my experience. Look at the APIs and frameworks and code conventions and other people's code and use your own instincts and try to understand why the material is what it is and what the consequences of things are. What code in books almost never does is a plan for the unplanned, which is what error checking does. It only pays off when someone sends you an email and says, “I got error 321” instead of “hey, application is broken, yo.”

Good code is written for the future, both from the point of view of the programmer and from the point of view of the user.

Answer 15

[Purely subjective response]
For me, a good code is a form of art, like painting. I could go further and say that this is actually a drawing that includes the characters, colors, “shape” or “structure” of the code and all this is so readable / executable. The combination of readability, structure (that is, columns, indents, even variable names of the same length!), Colors (class names, variable names, comments, etc.) Do everything I like to see as a “beautiful” picture that can do me very proud or very hating my own code.

(As already mentioned, a very subjective answer. Sorry for my English.)

Answer 16

Secondly, Bob Martin's recommendation, "Clean Code."

"Beautiful code" was praised a couple of years ago.

Any McConnell books deserve attention.

Perhaps the "Pragmatic Programmer" will also be useful.

%

Answer 17

This is very well said in Fowler's book "Refactoring". This is the absence of all the "smells" that he describes throughout the book.

Answer 18

I did not see "Professional ASP.NET", but I would be surprised if it were better than OK. See this question for some books with really good code. (Of course, it depends, but the accepted answer is hard to beat.)

Answer 19

This is apparently a (should be) FAQ. There is an ACM article on fine code recently. It seems that a lot of attention is paid to easy reading / understanding. I would define this using an "easy to read / understand domain specialist." Indeed, good programmers tend to use better algorithms (instead of naive, easy-to-understand O (n ^ 2) algorithms) for any given problems that may be difficult to achieve if you are not familiar with the algorithm, even if a good programmer gives a link to the algorithm.

No one is perfect, including good programmers, but their code tends to be:

• Correctness and efficiency with proven algorithms (instead of naive and adhoc hacks)
• Clarity (comment for intent with respect to non-trivial algorithms)
• Completeness to cover the basics (coding agreement, version control, documentation, unit tests, etc.).
• Extraordinary Essence (DRY)
• Reliability (resistance to arbitrary input and violation of change requests)

Answer 20

Second recommendation for Uncle Bob is "clean code." but you can take a look at http://www.amazon.com/Implementation-Patterns-Addison-Wesley-Signature-Kent/dp/0321413091 , as I think this concerns your specific question a little better. a good code should jump from the page and tell you what it does / how it works.

Answer 21

Jeff Atwood wrote a good article on how encoders are the first link: http://www.codinghorror.com/blog/archives/001188.html

When you are a machinist, you always need to be elegant in your work, having a strict and correct "grammar" is very important. Now converting this to "programming" typing will have the same result.

Structure

Comments

Regions

I am a programmer, which means that during my training I came across different languages, but my programs always "felt" the same as my letter on fekberg.wordpress.com, I have a "special" way to enter.

Now programming various applications and in different languages, such as Java, C #, Assembler, C ++, C, I came to the "standard" writing that I like.

I see everything as “boxes” or regions, and each region explains this by commenting. A region can be a "class", and within this region I have several methods for properties that I can call "Access Methods" or such, and each property and region has its own commentary explanations.

This is very important, I always see my code, which I do, because "being part of the api" is VERY important when creating the API structure and elegance.

Think about it. Also read my article on Communication issues when adapting outsourcing , which explains roughly how bad code can conflict, Enterpret as you like: http://fekberg.wordpress.com/2008/12/14/communication-issues-when-adapting -outsourcing /

Answer 22

Good code is easy to understand, easy to maintain, and easy to add. Ideally, it is also as effective as possible, without sacrificing other indicators.

Answer 23

Great code for me is something that is easy to understand, but complicated. What makes you go, "wow, of course, why didn't I think about that?" Really good code is not hard to understand, it just solves the problem at right angles (or in a recursive way, if it's even easier).

Answer 24

Good code is where you know what the method does on behalf of. Bad code is where you need to determine what the code does to understand the name.

Good code is where, if you read it, you can understand what it does, not as long as it takes to read it. Bad code is where you end up looking at it, trying to figure out what it does.

Good code has things named so that unnecessary unnecessary comments.

Good code tends to be short.

Good code can be reused to do what it does elsewhere, as it does not rely on things that are not really related to its purpose.

Good code, as a rule, is a set of simple tools for creating simple tasks (well-organized ways to create more complex tasks). Bad code is usually a huge multi-purpose tool that is easy to break and hard to use.

Answer 25

Code is a reflection of programmer skills and thinking. Good programmers always keep an eye on the future - how the code will function when requirements or circumstances are not quite what they are today. How much will it be? How convenient is it when I do not support this code? How to reuse code so that someone else doing such things can reuse the code and not write it again. What when someone tries to understand the code I wrote.

When a programmer has this thinking, all other things fit in perfectly.

Note. The code base is processed by many programmers over time, and usually the programmer does not have a specific code base designation. Therefore, a good code reflects all the standards of the company and the quality of their workforce.

Answer 26

(I use the “he” below because this is the person I strive to be, sometimes with success).

I believe that the core of a good programmer philosophy is that he always thinks: "I will code myself in the future, when I forget everything about this task, why I worked on it, what were the risks and even how this code should have worked" .

Thus, its code should:

• Work (no matter how fast the code gets the wrong answer. In the real world, there is no partial credit).
• Explain how he knows that this code works. This is a combination of documentation (javadoc is my choice), exception handling and test code. In a very real sense, I believe that line for line, test code is more valuable than functional code, if for no other reason than explains “this code works, this is how it should be used, and that’s why I should get paid. "
• Be supported. Dead code is a nightmare. Maintaining legacy code is hard work, but it needs to be done (and remember that this is a “legacy” the moment it leaves your table).

On the other hand, I believe that a good programmer should never do such things:

• Obsessed with formatting. There are many IDEs, editors and cute printers that can format the code according to the standard or personal preference that you think is appropriate. I use Netbeans, I set the format parameters once and from time to time I press alt-shift-F. Decide how you want the code to look, customize the environment, and let the tool do the work.
• Obsessed with naming conventions through human communication. If the naming convention leads you along the road, calling your classes “IElephantProviderSupportAbstractManagerSupport” rather than “Zookeeper”, change the standard before making it harder for the next person.
• Forget that he works as a team with real people.
• Forget that the main source of coding errors is now on his keyboard. If there is a mistake or mistake, he must first look at himself.
• Forget what's going on around you. Any work he does now to make his code more accessible to future readers will almost certainly benefit him directly (because who will be the first to ask to see his code?).

Answer 27

If you write code in C ++, there is a very good book with excellent coding standards that we refer to in uni, which is called: " C ++ Coding Standards: 101 Rules , Recommendations and Recommendations" "Herb Sutter, Andrei Alexandrescu and Bjarn Straustrup.

Answer 28

• Works
• It has unit tests that prove that it works.

The rest is icing ...

Answer 29

• The best code has a certain elegance that you recognize as soon as you see it.
• It looks crafted, with care and attention to detail. This, obviously, was done with someone with skill and has the art of it - you could say that it looks sculpted and polished, not rough and finished.
• It is consistent and easy to read.
• It breaks down into small, very weak functions, each of which does one thing and does it well.
• It is minimally connected, which means that there are few dependencies and is strictly controlled, usually with the help of ...
• Functions and classes are dependent on abstractions, not on implementations.

Answer 30

Ironically, a better programmer is less than indispensable, he / she becomes because the received code is better served by someone (as indicated by the general agreement of Eran Halperin).

My experience suggests otherwise, also true. worse than a programmer, it is more difficult to maintain his / her code, therefore it becomes more indispensable , since no other soul can understand the riddles.