The Artima Developer Community
Sponsored Link

Weblogs Forum
The Principles of Good Programming

26 replies on 2 pages. Most recent reply: Mar 10, 2017 8:08 PM by Anthony Rogan

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 26 replies on 2 pages [ 1 2 | » ]
Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

The Principles of Good Programming (View in Weblogs)
Posted: Jul 24, 2011 1:19 PM
Reply to this message Reply
Summary
Over the years I have found that following a relatively small number of fundamental guiding principles has helped me become a much more effective programmer.
Advertisement

Today's post is a lightly edited repost from my blog at The Area, a web-site dedicated to users of Autodesk media and entertainment products. I came up with this list of principles to help with a recent C# training I gave, and I thought that members of the Artima.com community could appreciate these principles and have some interesting insights to share.

Principles of Good Programming

The principles of good programming are closely related to principles of good design and engineering. The following programming principles have helped me over the years become a better programmer, and I believe can help any developer become more efficient and to produce code which is easier to maintain and that has fewer defects.

DRY - Don’t repeat yourself - This is probably the single most fundamental tenet in programming is to avoid repetition. Many programming constructs exist solely for that purpose (e.g. loops, functions, classes, and more). As soon as you start repeating yourself (e.g. a long expression, a series of statements, same concept) create a new abstraction. http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

Abstraction Principle - Related to DRY is the abstraction principle “Each significant piece of functionality in a program should be implemented in just one place in the source code.” http://en.wikipedia.org/wiki/Abstraction_principle_(programming)

KISS (Keep it simple, stupid!) - Simplicity (and avoiding complexity) should always be a key goal. Simple code takes less time to write, has fewer bugs, and is easier to modify. http://en.wikipedia.org/wiki/KISS_principle

Avoid Creating a YAGNI (You aren’t going to need it) - You should try not to add functionality until you need it. http://en.wikipedia.org/wiki/YAGNI

Do the simplest thing that could possibly work - A good question to ask one’s self when programming is “What is the simplest thing that could possibly work?” This helps keep us on the path towards simplicity in the design. http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html

Don’t make me think - This is actually the title of a book by Steve Krug on web usability that is also relevant in programming. The point is that code should be easily read and understood with a minimum of effort required. If code requires too much thinking from an observer to understand, then it can probably stand to be simplified http://www.sensible.com/dmmt.html

Open/Closed Principle - Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. In other words, don't write classes that people can modify, write classes that people can extend. http://en.wikipedia.org/wiki/Open_Closed_Principle

Write Code for the Maintainer - Almost any code that is worth writing is worth maintaining in the future, either by you or by someone else. The future you who has to maintain code often remembers as much of the code, as a complete stranger, so you might as well always write for someone else. A memorable way to remember this is “Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.” http://c2.com/cgi/wiki?CodeForTheMaintainer

Principle of least astonishment - The principle of least astonishment is usually referenced in regards to the user interface, but the same principle applies to written code. Code should surprise the reader as little as possible. The means following standard conventions, code should do what the comments and name suggest, and potentially surprising side effects should be avoided as much as possible. http://en.wikipedia.org/wiki/Principle_of_least_astonishment

Single Responsibility Principle - A component of code (e.g. class or function) should perform a single well defined task. http://en.wikipedia.org/wiki/Single_responsibility_principle

Minimize Coupling - Any section of code (code block, function, class, etc) should minimize the dependencies on other areas of code. This is achieved by using shared variables as little as possible. “Low coupling is often a sign of a well-structured computer system and a good design, and when combined with high cohesion, supports the general goals of high readability and maintainability” http://en.wikipedia.org/wiki/Coupling_(computer_programming)

Maximize Cohesion - Code that has similar functionality should be found within the same component. http://en.wikipedia.org/wiki/Cohesion_(computer_science)

Hide Implementation Details - Hiding implementation details allows change to the implementation of a code component while minimally affecting any other modules that use that component. http://en.wikipedia.org/wiki/Information_Hiding

Law of Demeter - Code components should only communicate with their direct relations (e.g. classes that they inherit from, objects that they contain, objects passed by argument, etc.) http://en.wikipedia.org/wiki/Law_of_Demeter

Avoid Premature Optimization - Don’t even think about optimization unless your code is working, but slower than you want. Only then should you start thinking about optimizing, and then only with the aid of empirical data. "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" - Donald Knuth. http://en.wikipedia.org/wiki/Program_optimization

Code Reuse is Good - Not very pithy, but as good a principle as any other. Reusing code improves code reliability and decrease development time. http://en.wikipedia.org/wiki/Code_reuse

Separation of Concerns - Different areas of functionality should be managed by distinct and minimally overlapping modules of code. http://en.wikipedia.org/wiki/Separation_of_concerns

Embrace Change - This is the subtitle of a book by Kent Beck, and is also considered a tenet of extreme programming and the agile methodology in general. Many other principles are based on the concept that you should expect and welcome change. In fact very old software engineering principles like minimizing coupling are related directly to the requirement of making code easier to change. Whether or not you are an extreme programming practitioner, this approach to writing code just makes sense. http://www.amazon.com/gp/product/0321278658


Jack Unrue

Posts: 1
Nickname: jdunrue
Registered: Jul, 2011

Re: The Principles of Good Programming Posted: Jul 24, 2011 6:49 PM
Reply to this message Reply
I agree with everything in your list, but you have nothing about tests? I'd add one more entry:

- Unless a piece of code has at least one test, assume it's broken. Even with a test, it's still probably broken, so think about adding another test. Especially for new code.

Nick Roosevelt

Posts: 1
Nickname: nroose
Registered: Jul, 2011

Re: The Principles of Good Programming Posted: Jul 25, 2011 3:54 PM
Reply to this message Reply
Nice write-up. A few too many principles, though, if you ask me.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: The Principles of Good Programming Posted: Jul 25, 2011 5:06 PM
Reply to this message Reply
> - Unless a piece of code has at least one test, assume
> it's broken.

I like this one.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: The Principles of Good Programming Posted: Jul 25, 2011 5:10 PM
Reply to this message Reply
> Nice write-up. A few too many principles, though, if you
> ask me.

Thanks. I kind of agree. I think the big three are:

1) Don't repeat yourself
2) Keep it simple
3) Embrace change

I think everything else can be directly related to one of those three main principles. Perhaps some day I will do a better job of grouping them.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: The Principles of Good Programming Posted: Jul 26, 2011 1:49 AM
Reply to this message Reply
It's good to see you writing here again. All the items on the list are useful but, as has already been pointed out, the list is way too long. (Perhaps some of these principles should be applied to the list of principles.)

Don't Repeat Yourself, Code Reuse is Good, Do the simplest thing that could possibly work, KISS, Don't Make Me Think, You aren’t going to need it and Principle of Least Astonishment are essentially variations on the same principle, expressed in different ways.

Similarly, Law of Demeter is one mechanism for helping to achieve both Minimize Coupling and Separation of Concerns which, in turn, are diffent views of much the same principle Maximize Cohesion.

Now you have a hierarchy: Core principles, aspects of those principle (and then detail). If you get down to the level of the detail, include counter-examples. All priciples have limits and knowing these limits adds greatly to their value and validity. For instance, the simplest solution is not necessarily the best solution. Sometimes it's good to write astonishing code. Reuse of code may mean breaking many of the other principles, etc.

Finally, don't forget Principle Zero. Working code trumps principled code every time.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

I think Law of Demeter has issues Posted: Jul 26, 2011 9:51 AM
Reply to this message Reply
It often conflicts with other, better principles.

Let object A contain a Collection. Object B has access to A. According to Law of Demeter, it cannot call a.getTheCollection().foo().

A could implement all those methods of Collection, which is tedious, and violates DRY. Alternatively, it might extend Collection (or be tempted to) which violates "contain, don't extend"

IMO, if the contained object is a "well known abstraction", one should ignore Law of Demeter.

Michael Hobbs

Posts: 51
Nickname: hobb0001
Registered: Dec, 2004

I think Open/Closed Principle has issues too Posted: Jul 26, 2011 10:47 AM
Reply to this message Reply
I'm not a terribly big fan of the Open/Closed Principle, either. Maybe it's my Python background, but when you close a class to any updates, you usually wind up with a wicked web of tangled inheritance as a result. (I'm looking at you, Abatross. http://i.imgur.com/FgmXk.png http://www.object-craft.com.au/projects/albatross/)

The resulting tangled mess violates the KISS, the Do the simplest thing that could possibly work, the Don’t make me think, and probably the YAGNI principles.

The Open/Closed Principle may be a good idea for anyone who ships closed-source libraries, but the number of developers who work in such a context is very very few.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: The Principles of Good Programming Posted: Jul 26, 2011 6:46 PM
Reply to this message Reply
> It's good to see you writing here again.

Hi Vincent, thanks!

> All the items on
> the list are useful but, as has already been pointed out,
> the list is way too long.

Agreed. You make some good points, and I think that pointing out the relations between principles is worthwhile.

Marshal Joel

Posts: 1
Nickname: marshaljoe
Registered: Jul, 2011

Re: The Principles of Good Programming Posted: Jul 26, 2011 9:51 PM
Reply to this message Reply
Very Good. Keep it up.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: I think Open/Closed Principle has issues too Posted: Jul 26, 2011 10:44 PM
Reply to this message Reply
Somewhat agreed, but it depends what you are writing. If it is something to be publically distributed to a wide audience, or it is super-critical code (e.g. medical device, security) then closing the class makes more sense - you don't trust users of your code to extend it correctly.

If it is internal business logic / domain code, you can (perhaps) trust users to extend it correctly if needed. And, in my experience, some extension will almost always be needed!

John Wellbelove

Posts: 72
Nickname: garibaldi
Registered: Mar, 2008

Re: I think Open/Closed Principle has issues too Posted: Jul 27, 2011 1:25 AM
Reply to this message Reply
Although I tend to agree with many of the items listed I do have issues with aspects of two of them.

Avoid Creating a YAGNI (You aren’t going to need it)

Do the simplest thing that could possibly work


If had used those principles whilst designing recent projects I would have caused myself a tremendous amount of extra work, as the lack of application of foresight would have required re-design and re-factoring at several stages.

For example, a project used a CCD camera that produced 8bit images. Using the above principles I should have created 8bit image algorithms using 8bit image containers and so on. It would have been the simplest thing and we didn't need greater bit depth.

Fine, except that anyone in my job would know that working with greater bit depths was inevitable.
My solution was to produce a templated image container/iterator/algorithm architecture that could cope with any bit depth or sample type. The amount of initial work was slightly greater, but not excessively so.
The pay-off was that the projects that came afterwards had substantially reduced coding requirements because of the flexible image library. (i.e. DRY)

It seems that the usual 'agile' approach is to use YAGTNI
and DTSTTCPW to produce code specific to a problem and then 're-factor' (rip-up and re-write) to extract the commonality.

That's just plain daft and wasteful!

I prefer to use that thing between my ears called a 'brain' and program furher ahead than the next five minutes by applying the principle of
Do It Right First Time

I would modify YAGTNI to YAGNTIYBIYDTIIAYWCYALMWL
'You Aren't Going To Need It Yet But If You Don't Take It Into Account You Will Create Yourself A Lot More Work Later'

Alexandre Zani

Posts: 1
Nickname: armence
Registered: Jul, 2011

Re: I think Open/Closed Principle has issues too Posted: Jul 27, 2011 8:03 AM
Reply to this message Reply
I think you're making two mistakes in your understanding of YAGNI.

First, YAGNI does not mean ignore the future. If you know that the next step is, you should of course keep it in mind. What YAGNI says is: If you're writing software for an 8-bit camera, don't write 16 bit algorithms. The reason is not just that it takes time to write that other algorithm. The reason is that when you write code others might start using it. And then when you need to change the code to match the actual requirements, (god knows marketing changes requirements every other day) you have to deal with breaking someone else's code and fixing it which is really unpleasant.

Second, it's a mistake to take YAGNI in isolation from the other principles. Separation of concern, DRY, abstraction principle etc all mean that you are going to write modular code that will be easy to maintain and change in the future. So writing your image handling code such that it will be easy to change the algorithms and data structures in the future is not a violation of YAGNI. It's a good application of the other principles.

John Wellbelove

Posts: 72
Nickname: garibaldi
Registered: Mar, 2008

Re: I think Open/Closed Principle has issues too Posted: Jul 27, 2011 9:16 AM
Reply to this message Reply
> What YAGNI says is: If you're writing software for
> an 8-bit camera, don't write 16 bit algorithms.

But that's the idea I don't agree with.
The point was that I spent the extra time to develop templated code so that I didn't write 8 and 16 bit image algorithms, I wrote one algorithm that worked for any bit depth. And if the algorithm needed updating then it was updated for all image types. Writing for just 8 bit depth would have been short-sighted and dumb.

Jan Samohyl

Posts: 14
Nickname: asgard
Registered: Feb, 2008

Re: I think Open/Closed Principle has issues too Posted: Aug 1, 2011 11:50 PM
Reply to this message Reply
> I would modify YAGTNI to YAGNTIYBIYDTIIAYWCYALMWL
> 'You Aren't Going To Need It Yet But If You Don't Take It
> Into Account You Will Create Yourself A Lot More Work
> Later'

Doesn't that mean, by definition, that "you are gonna need it" after all?

Flat View: This topic has 26 replies on 2 pages [ 1  2 | » ]
Topic: Is Scala Only for Computer Scientists? Previous Topic   Next Topic Topic: Decorators I: Introduction to Python Decorators

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use