Weblogs Forum - The Principles of Good Programming

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

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

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 26 replies on 2 pages [ « | 1 2 ]

Jan Samohyl

Posts: 14
Nickname: asgard
Registered: Feb, 2008

Re: The Principles of Good Programming

Posted: Aug 1, 2011 11:58 PM

> DRY - Don’t repeat yourself - This is probably the single most fundamental tenet in programming is to avoid repetition.

I disagree with this claim. DRY is not a fundamental tenet in programming at all. I think people wish it were, but it isn't.

Look at mainstream programming languages. There is very little of actual support for DRY. The languages that supports DRY principle the most are probably Common Lisp with its macro system, Forth with its immediate words and Haskell with its higher order functions. Java/C++/C# don't even come close.

And as you can see from adoption rate of Lisp, Forth and Haskell, DRY has also its disadvantages (worse readability?). So no, DRY is not that important as it is made to be; though I certainly wish it were, because I like Common Lisp and Forth (I don't know much about Haskell, and have reservations about the purity of functions).

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: I think Open/Closed Principle has issues too

Posted: Aug 4, 2011 9:49 AM

> > 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.

While there is something to YAGNI (I'll wager that we all have worked with over-designed systems), I agree strongly with John that blindly following this is stupid.

Where I work, we are building the Nth version of a large number of systems. We have to do this because of the brittleness of the previous implementations. So when we are building say a fundamental web service specification, we already have a pretty good idea what it needs to support. Basically, the business we are in hasn't changed and we needed to have a certain functionality 5 out of the last 5 times we've done it. It makes no sense for us to pretend like we don't know we will need it the 6th time but the people who walk in off the street talking about stuff like YAGNI don't have that background information.

Certain aspects of system design are extremely costly to add in later. For example, how fault-tolerance is implemented can fundamentally change the approach of a system. The best analogy I can think of is that when you build a house, you better think ahead before you lay the foundation. Obviously, software isn't a house but there are ways to paint yourself into a corner when building software.

A good example of this was a system I heard about where all dollar amounts were stored in 16 bit ints. They were smart enough not to use floats but didn't create/use a special money type or anything (YAGNI). But then, a potential customer wanted to use the system to sell big ticket items like airplanes and they lost out on a big contract.

A little bit of forethought can go a long way. It just needs to be balanced. The more experience you have the more likely your foresight will pay off and the less you need to blindly adhere to YAGNI.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: I think Open/Closed Principle has issues too

Posted: Aug 4, 2011 10:17 AM

It's probably better to describe these aspects of coding as aspirations rather than principles. Calling them principles gives them the veneer of being rules that must be followed. In the worst case keeping to the rules becomes as important as delivering the customer requirements, with any compromise then seen as a Bad Thing. Aspirations, on the other hand, are things that have to be aimed for, rather than hit. Seen that way, they are a Good Thing. Not meeting them is not seen as a failure, and compromise and balance is built in to their working.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: I think Open/Closed Principle has issues too

Posted: Aug 4, 2011 2:28 PM

> It's probably better to describe these aspects of coding
> as aspirations rather than principles.
> Calling them principles gives them the veneer of being
> g rules that must be followed. In the worst case keeping
> to the rules becomes as important as delivering the
> customer requirements, with any compromise then seen as a
> Bad Thing. Aspirations, on the other hand, are
> things that have to be aimed for, rather than hit. Seen
> that way, they are a Good Thing. Not meeting them
> is not seen as a failure, and compromise and balance is
> built in to their working.

I think the problem with a lot of these rules of thumb is that they are stated in terms that are subject to wildly different interpretations. All of these contain an essential truth but understanding what those truths are requires a breadth and depth of knowledge that the target audience does not have.

For example, a lot of people might argue that the simplest thing that could possibly work is to eliminate all layers of abstraction. You would look at the code and know exactly what it does. Someone else would say that the simplest thing possible is to name all methods 'eval' and use polymorphism for everything. 'Simple' is inherently subjective and to make these things truly meaningful and useful to the beginner, you have to have a detailed explanation of what 'simple' means. I find these kinds of things can actually be detrimental for this reason.

Rudolf Pecinovský

Posts: 1
Nickname: rudyment
Registered: Jul, 2004

Re: The Principles of Good Programming

Posted: Feb 9, 2012 7:29 AM

I thing you forgot one of most important principles:
"Program to an 'interface', not an 'implementation'".
Probably it is so natural to you that you forgot that many programmers have problems with its acceptance.

Michael Stueben

Posts: 4
Nickname: csteacher
Registered: Nov, 2015

Re: The Principles of Good Programming

Posted: Aug 30, 2016 1:51 PM

Here is my advice to my high school students. Alas, it takes experience to have opinions about such advice, and high school students don't yet have that experience.

Advice for Developing Programmers

1. Limit functions to a single task, usually.
2. Label and align your output.
3. Document your programs at the top: name, date, class period (maybe course and instructor),
title, and program description. Watch your spelling, grammar, and punctuation.
4. Code with line numbers and never indent less than three spaces.
5. Use vertical alignment in your code, if it will emphasize significant relationships.
6. Do not use reserved words for identifiers or file names—e.g., random, max, print, etc.
7. Refactor (= redesign) your programs after they work to be more readable (IMPORTANT!).
8. Use step-wise refinement.
9. Write self-documenting code (descriptive identifiers, usually verb-object function names)
and thereby minimize comments.
10. Always print the run time, and maybe some other statistics, for every program.
11. Avoid magic numbers, unless they make the code significantly easier to understand.
12. Avoid global variables, but global constants are OK.
13. Do not write clever code (code that doesn’t immediately look like what it does), when
simpler code will do.
14. Choose readability over both optimization for speed and optimization for memory use.
15. Anticipate bugs by using defensive measures (asserts and error traps), but don’t overdo it.
16. Test every function upon completion (the golden rule). Untested code is broken code.
17. For a complicated algorithm, consider writing the tests before you write the code, and
consider running hundreds of randomly generated tests.
* * *

18. Do not start on the next assignment/function until you have finished the previous one.
19. When coding you need total focus. Avoid the chatty classmate.
20. Save every assignment on at least two different physical devices.
* * *

21. Write some code every week. Do not regress.
22. Hang around smart people and try to get them to talk shop.
23. Read the code of other programmers.
24. Try hard to avoid cheating.
25. Come to your problems with a history of attempting challenging problems.
26. Do not let schooling, grades, and outside activities sabotage your education. You are
responsible for your learning, not the school.

Mario Vápeník

Posts: 5
Nickname: ctverec
Registered: Jan, 2017

Re: The Principles of Good Programming

Posted: Jan 29, 2017 1:41 AM

Thanks for the list. I would sign it. Maybe comment some items. Open/close principle is something hard to induct directly into your approach or skill. I find it rather something you can detect backwards in your code as a healthy feature. Concerning single responsibility principle, it is little bit vague. It can be read as "simple" responsibility principle and lead to higher granularity of your design than optimal. Law of demeter is debatable too. Does it mean that shared static methods and tools are not welcome? I couldn't agree quite.
In summarize, I like the list as a genuine one. What I personally can't say about theory of so called legacy code and unit tests coverage. As well theories of if-less programming I find little bit extreme.

Mario Vápeník

Posts: 5
Nickname: ctverec
Registered: Jan, 2017

Re: I think Open/Closed Principle has issues too

Posted: Jan 29, 2017 1:47 AM

Hello, I use C# and find DRY one of fundamental principles. We probably understand different what it means.

Mario Vápeník

Posts: 5
Nickname: ctverec
Registered: Jan, 2017

Re: I think Open/Closed Principle has issues too

Posted: Jan 29, 2017 1:49 AM

It was reply to Jan Samohyl's post. It looks like Replies don't match the origin.

Mario Vápeník

Posts: 5
Nickname: ctverec
Registered: Jan, 2017

Re: The Principles of Good Programming

Posted: Jan 29, 2017 1:51 AM

Now reply to Rudolf Pecinovský: Programming against interaces I find one of the horrible myths of today's programming. Just opposite is the good. Use the interface just when it is useful. Otherwise you attack understandability.

Mario Vápeník

Posts: 5
Nickname: ctverec
Registered: Jan, 2017

Re: The Principles of Good Programming

Posted: Jan 29, 2017 2:01 PM

To Rudolf Pecinovský again: But I don't say I must be true. Something came to my mind. If I have a class which is unique (has no mates, only descendants), so it doesn't need an interface, but the class itself isn't simple, has many various public members, we can make it inherit from more interfaces to have better views on it's aspects. Than programming to interfaces can help the understandability.

Anthony Rogan

Posts: 1
Nickname: trogan
Registered: Mar, 2017

Re: The Principles of Good Programming

Posted: Mar 10, 2017 8:08 PM

Principle no. 1.

If it is not perfectly obvious that code will work first time every time, rethink it.

Principle no. 2.

Code should minimise reliance on past events.

principle no 2a. All totals should be derived from currently existing objects.

Flat View: This topic has 26 replies on 2 pages [ « | 1 2 ]

Previous Topic

Next Topic