|
List Info
Thread: good guide to programming style
|
|
| good guide to programming style |

|
2007-01-22 23:05:21 |
|
| At $WORK I support a group of analysts, who are generally
very smart but they are not familiar with good programming
practices. Mostly Window users getting a foot hold in unix by
following examples from not so well written Fortran or R examples.
Unfortunately "good" programming is not something I can just define
in a short training session. And, it's too easy (and painful) to
just identify poor programming techniques or mistakes. So, I'd
like to put some kind of training together and was wondering if
anyone here could provide some interesting websites to help the
process?
Here are some I'm planning to narrate, depending on which are most
effective.
[http://www.dwheeler.com/secure-programs/ Secure Programming for Linux and Unix HOWTO -- Creating Secure Software]
[http://www.faqs.org/docs/artu/ch01s06.html Basics of the Unix Philosophy]
[http://www.shelldorado.com/ good coding practices for Bourne Shell and Korn Shell script programmers.]
[http://www-128.ibm.com/developerworks/aix/library/au-hook_duttaC.html Best practices for programming in C]
[http://stommel.tamu.edu/~baum/programming.html Programming Texts and Tutorials] -- meta site
[http://mindprod.com/jgloss/unmain.html unmaintainable code]
Know any others? Most of those are way too advanced for the group,
"Why I mastered Pascal before I embarked on assembly code, things
to know before you write your first bug" is the sort generalized
document I'm looking for. Any ideas?
// George
--
George Georgalis, systems architect, administrator <
|
| Re: good guide to programming style |

|
2007-01-23 06:20:02 |
|
| George Georgalis wrote:
> Unfortunately "good" programming is not something I can just define
> in a short training session. And, it's too easy (and painful) to
> just identify poor programming techniques or mistakes. So, I'd
> like to put some kind of training together and was wondering if
> anyone here could provide some interesting websites to help the
> process?
Good list of links, not seen all of them before.
They sound like abstract problem solvers so help them link their work to
software engineering discipline, include something like design patterns
and basic design techniques such as abstract data types and OO.
Make sure they are familiar with the basic tools, version control, bug
tacking, test methodology, performance analysis etc. You started on that
with unix philosophy and shell scripting.
They are experts in their field so they really need an overview of
techniques and strategies. Introduce the main concepts explaining when
and why they are useful, leave them to work through the detail of copy
constructors and finite precision of float and doubles. All this needs
to be backed up with copious detail such as standards documents and
reference material.
Might be worth checking out computer science departments web sites, they
often have course material online.
Great books:
Numerical Recipes
Design Patterns (Gang of Four)
Computer graphics principles and practice.
Knuth: The Art of Computer Programming
http://c2.com/doc/oopsla89/paper.html A Laboratory For Teaching
Object-Oriented Thinking
http://ootips.org/ Object Orientation Tips
http://www.softdevarticles.com/
Simon
|
| Re: good guide to programming style |

|
2007-01-25 01:57:40 |
|
| On 1/22/07, George Georgalis galis.org> wrote:
> Here are some I'm planning to narrate, depending on which are most
> effective.
> Know any others? Most of those are way too advanced for the group,
> "Why I mastered Pascal before I embarked on assembly code, things
> to know before you write your first bug" is the sort generalized
> document I'm looking for. Any ideas?
Kernighan and Pike - The practice of programming
(assuming nobody else has mentioned it yet)
Cheers,
Al
|
| Re: good guide to programming style |

|
2007-01-25 02:10:40 |
|
On Tue, Jan 23, 2007 at 12:05:21AM -0500, George Georgalis wrote:
> At $WORK I support a group of analysts, who are generally
> very smart but they are not familiar with good programming
> practices. Mostly Window users getting a foot hold in unix by
> following examples from not so well written Fortran or R examples.
>
> Unfortunately "good" programming is not something I can just define
> in a short training session. And, it's too easy (and painful) to
> just identify poor programming techniques or mistakes. So, I'd
> like to put some kind of training together and was wondering if
> anyone here could provide some interesting websites to help the
> process?
IMHO you need to show why some things are 'bad practice', because 'good
practice' is what is left after you remove all the bad practice! and knowing
some bad practice will (should) help people identify others themselves.
I'd consider:
- KISS (keep it simple stupid)
- namespace preservation (and I don't mean C++ namespaces)
eg all members of a structure have a short prefix, all gloabal defines
and functions have a prefix.
- consistant and clear layout [1]
David
[1] Considers the following fragment:
....
....
}
while (.......................................................................
{
....
....
Is it the bottom of a 'do' loop or the top of a 'while loop'.
--
David Laight: david l8s.co.uk
|
| Re: good guide to programming style |

|
2007-01-25 22:53:11 |
|
| On Fri, Jan 26, 2007 at 11:49:03AM +1100, jonathan michaels wrote:
>i've been in this kind of position on several ocassion in my chequuered
>career, i'ver read all teh posts (so far) in this thread and aggree
>that all teh advice is quite good, but grograming is a two way street,
>after its written it needs to be used and for that it needs to have a
>usable user interface,
actually, the only reason my group writes programs is to get
numbers, nobody outside the group runs the programs once the
numbers are derived. that said,
>the visual display of quantitative information
>isbn 0961392142
we do write reports and that is a classic book that our graphing
experts might be able to make use of. Certainly the others too
where interesting browsing on amazon.
// George
--
George Georgalis, systems architect, administrator <
|
| Re: good guide to programming style |

|
2007-01-25 23:18:46 |
|
On Thu, Jan 25, 2007 at 08:10:40AM +0000, David Laight wrote:
>On Tue, Jan 23, 2007 at 12:05:21AM -0500, George Georgalis wrote:
>> At $WORK I support a group of analysts, who are generally
>> very smart but they are not familiar with good programming
>> practices. Mostly Window users getting a foot hold in unix by
>> following examples from not so well written Fortran or R examples.
>>
>> Unfortunately "good" programming is not something I can just define
>> in a short training session. And, it's too easy (and painful) to
>> just identify poor programming techniques or mistakes. So, I'd
>> like to put some kind of training together and was wondering if
>> anyone here could provide some interesting websites to help the
>> process?
>
>IMHO you need to show why some things are 'bad practice', because 'good
>practice' is what is left after you remove all the bad practice! and knowing
>some bad practice will (should) help people identify others themselves.
the more I read http://www.soberit.hut.fi/mmantyla/BadCodeSmellsTaxonomy.htm
the more I agree
>- KISS (keep it simple stupid)
>- namespace preservation (and I don't mean C++ namespaces)
> eg all members of a structure have a short prefix, all gloabal defines
> and functions have a prefix.
Good idea! We have discussed namespace collision but that's about it...
>- consistant and clear layout [1]
>
> David
>
>[1] Considers the following fragment:
> ....
> ....
> }
> while (.......................................................................
> {
> ....
> ....
>Is it the bottom of a 'do' loop or the top of a 'while loop'.
I don't understand your example, "while" is the beginning of a new
loop. what are you saying?
// George
--
George Georgalis, systems architect, administrator <
|
| Re: good guide to programming style |

|
2007-01-26 00:19:04 |
|
On Wed, Jan 24, 2007 at 11:57:40PM -0800, Alan Horn wrote:
>On 1/22/07, George Georgalis galis.org> wrote:
>
>>Here are some I'm planning to narrate, depending on which are most
>>effective.
>
>>Know any others? Most of those are way too advanced for the group,
>>"Why I mastered Pascal before I embarked on assembly code, things
>>to know before you write your first bug" is the sort generalized
>>document I'm looking for. Any ideas?
>
>
>Kernighan and Pike - The practice of programming
>(assuming nobody else has mentioned it yet)
I'm glad you mentioned. It was the book I was looking for when I
first started out this task, but I didn't know the name or who
wrote it. I found "Firewalls and Internet Security: Repelling the
Wily Hacker" but that wasn't it.
// George
--
George Georgalis, systems architect, administrator <
|
| Re: good guide to programming style |

|
2007-01-26 07:11:05 |
|
| All of this advice is summed up in the following aphorism:
Remember that you write code for three audiences:
The computer, for which it must be correct
Your muse, for whom it must be elegant
The poor schmuck who has to modify it,
for whom it must be comprehensible
Dan Killoran
|
| Re: good guide to programming style |

|
2007-01-26 14:28:25 |
|
On Fri, Jan 26, 2007 at 12:18:46AM -0500, George Georgalis wrote:
> >
> >[1] Considers the following fragment:
> > ....
> > ....
> > }
> > while (.......................................................................
> > {
> > ....
> > ....
> >Is it the bottom of a 'do' loop or the top of a 'while loop'.
>
>
> I don't understand your example, "while" is the beginning of a new
> loop. what are you saying?
Ah sorry, didn't you see the:
do
{
....
I deleted from the top of the fragment.
The code below is just a block that exists in order a have its own local vars.
David
--
David Laight: david l8s.co.uk
|
[1-9]
|
|