General Programming tips

[js_dev]

Here is a bunch of good tips for progamming, in general:

Murphy's Law of programming states: "The sooner you start coding your
program, the longer it is going to take." Design to great detail and
elaborately and then only, start coding. Falls very much in line with
the practice of first writing the logic in english-like words first and
then substituting the words by the code of you language. Of course, you
need to know the language well- what algorithms are directly supported
by the libraries of the language and what are not. For example, Java
now has Arrays.sort(Object[]); which sorts "according to natural order"
(meaning numercially for float[], int[] and double[] and alphabetically
for String[] etc.), so you need not write a separate sort method.
Arrays also has Binary search method - so you do not need to write a
separate binary search module.

It pays handsomely to know the API well but obviously it is a long-term
process. Coding tiem is reduced manifold if you know which fucntion is
where and does exactly what. Compiled help helps reduce the searching
time, but the gains are hardly close to the situation when you know in
your mind what the code should look like.

While learning a new language or API, it is an excellent practice to
make flash cards or simple one line notes of all the important things
you learn in a session and at the end of the session try to revise in
your mind all those points. Keep the question on one side of the card
and answers on the other. There is a good piece of software called
jMemorize which helps you do just this. Have a look at it.

 

[Patricia Shanahan]

Here is a bunch of good tips for progamming, in general:

Murphy's Law of programming states: "The sooner you start coding your
program, the longer it is going to take." Design to great detail and
elaborately and then only, start coding. Falls very much in line with
the practice of first writing the logic in english-like words first and
then substituting the words by the code of you language. Of course, you
need to know the language well- what algorithms are directly supported
by the libraries of the language and what are not. For example, Java
now has Arrays.sort(Object[]); which sorts "according to natural order"
(meaning numercially for float[], int[] and double[] and alphabetically
for String[] etc.), so you need not write a separate sort method.
Arrays also has Binary search method - so you do not need to write a
separate binary search module.

Murphy's Law, for programming or anything else, states that "If anything
can go wrong, it will.". Whether or not the rule you state above is
valid, it needs a different name, because the actual Murphy's Law is far
too important to be forgotten or go nameless.

There are arguments both ways on how long to spend on designing the
whole program in advance vs. designing the implementation of each
feature just before coding it. See anything on "agile programming".

I think it depends mainly on the cost of changing a decision. Think long
and hard about decisions that are going to be expensive or impossible to
change, such as the interface a widely distributed library will offer to
its users. Make quick decisions, and get on with life, for things that a
refactoring tool can fix in a couple of minutes. Often, the right answer
will become obvious as you add features to the program.

I agree strongly with the advice about using language features rather
than reimplementing them, though I'm not sure how it relates to the rest
of the paragraph.

While learning a new language or API, it is an excellent practice to
make flash cards or simple one line notes of all the important things
you learn in a session and at the end of the session try to revise in
your mind all those points. Keep the question on one side of the card
and answers on the other. There is a good piece of software called
jMemorize which helps you do just this. Have a look at it.

Why? I know too many languages, and the API's are too rich, for it to be
worth while spending my time on memorization. The web is an excellent
extended memory. For example, I rarely code in Java for more than a few
minutes without opening up its API documentation in a browser window.

Of course, I naturally remember things I use frequently enough, but that
happens without flash cards.

Search engines can also be useful for finding out how to do things. The
second result, and first java.sun.com result, in a Google search for
"java sort" is the API documentation for Arrays.

Patricia

 

[Joan]

Murphy's Law, for programming or anything else, states that "If
anything
can go wrong, it will.". Whether or not the rule you state
above is
valid, it needs a different name, because the actual Murphy's
Law is far
too important to be forgotten or go nameless.

</snip>

So is "murphy's law" a "best practice?" ;-)

 

[Patricia Shanahan]

</snip>

So is "murphy's law" a "best practice?" ;-)

Oddly enough, its entire value is in its tendency to challenge people to
circumvent it, by ensuring there is nothing that can go wrong.

Patricia

 

[Roedy Green]

There are arguments both ways on how long to spend on designing the
whole program in advance vs. designing the implementation of each
feature just before coding it. See anything on "agile programming".

One of the big problems is that customers have only a vague idea what
they want until you deliver the final product. So if you are trying
to reduce overall cost, it is best to deliver as little as possible
per cycle. That way you won't write a huge amount of code you end up
throwing away.

The customer gets smarter and smarter as you progress. They begin to
understand their true needs.

One technique to circumvent this is to spend time studying what the
customer does. Instead of asking him free form questions about what he
would like, you can ask questions of the form, "how useful would this
be to you? Would you prefer it work by method A or B?." You can say,
"Believe it or not, these are things I can offer you with almost no
effort." I remember customers being amazed that multiple sort orders
were no particular problem. It is very difficult in manual filing.
On the other hand, I can ease them away from trying to automate tasks
that are simple and not particularly time consuming for humans. You
need to understand the business.

If you write specs and interview, customers will swear they have told
you about all the exceptional cases. They invariably lie. They tell
you only about the COMMON exceptional cases. In a manual system, they
handle the rest on an ad hoc basis. With computers that seat of the
pants escape route usually disappears. You don't find out about this
until you go in production. This is why you have to observe the
business not just be told about it.

Another hint, interview people at all levels. The managers have a
naive simplified idealistic view of how their company really works.

One of the things hat initially attracted me to computer programming
was the licence it gave me to ask any question of anybody. At least
for a short time I understood banking better than the bankers,
transmission design better than the engineers because I combined
detailed knowledge from so many sources. The other pleasure is that
even after I forget that knowledge, the program does not.