Programming style is a set of rules or guidelines used when writing the
source code for a
computer program.
It is often claimed that following a particular programming style will help
programmers to read and
understand source code conforming to the style, and help to avoid introducing errors.

The programming style used in a particular program may be derived from the coding standards
or
code conventions of a company or other computing organization, as well as the preferences
of the author of the code. Programming styles are often designed for a specific
programming
language (or language family): style considered good in
C source code may not be appropriate for
BASIC source code, and so on. However, some rules are commonly applied to many languages.

In reality style recommendation are far from being absolute. Much depends on tools and language used.
Some extremely like structured programming or verification movement while containing some useful bits
more distract from writing a good program then help. Like Knuth noted the weakness of structure programming
is that it emphasize absence of goto, not the presence of structure.

Style can easily become a religious issue. And that's a bog big danger, as fanatics poison everything
they touch. Like Rob Pike aptly noted "Under no circumstances should you program the way I say to because
I say to; program the way you think expresses best what you're trying to accomplish in the program.
And do so consistently and ruthlessly."

As Dennis Ritchie noted "It is very hard to get things both right (coherent and correct) and usable
(consistent enough, attractive enough)". That's the matter of elegance. Most time making code shorter
improves maintainability but avoid overusing/abusing idioms.

Defensive programming

Defensive programming is a form of
defensive design intended to
ensure the continuing function of a piece of
software under unforeseen circumstances. Defensive programming practices are often used where high availability,
safety or security is needed.

Defensive programming is an approach to improve software and source code, in terms of:

Making the source code comprehensible – the source code should be readable and understandable so it is
approved in a code audit.

Making the software behave in a predictable manner despite unexpected inputs or user actions.

Overly defensive programming however introduces unnecessary code for errors impossible to even happen, thus
wasting runtime and maintenance costs. There is also the risk that the code traps or prevents too many exceptions,
potentially resulting in unnoticed, incorrect results.

The origin of this concept can be traded to the creation of ADA programming language (1977-1983) or even earlier. Former DOD standard for large scale safety critical software development
emphasized encapsulation, data hiding, strong typing of data, minimization of dependencies between parts to minimize impact of
fixes and changes.

One typical problem in large software changes that changes, fixing one problem creates another, or two. One way to fight this
problem of "increasing entropy with age" or loss of conceptual integrity is to institute a set of sanity checks which detect
abnormal parameters values (assertions or some similar mechanism) and such. In most systems resulting overhead is negligible but
the positive effect is great.

As an example of defensive programming style we can list Tom Christiansen recommendations for Perl language (which does not
have strict typing of variables and, by default, does not require any declaration of variables creating potential for
misspelled variables slipping into production version of the program):

use strict

#!/usr/bin/perl -w

Check all syscall return values, printing $!

Watch for external program failures in $?

Check $@ after eval"" or s///ee.

Parameter asserts

#!/usr/bin/perl -T (taint mode in which Perl distrust any data from outside world, see below)

Always have an else after a chain of elsifs

Put commas at the end of lists to so your program won't break if someone inserts another item
at the end of the list.

Out of those the most interesting is taint option (strict is also interesting but it simply partially fixes oversights in
the initial design of the language; Python uses more sound idea of typing values and requiring explicit conversion between values of
different types). Here is a quote from Perl Command-Line Options -
Perl.com:

The final safety net
is the -T option. This option puts Perl into "taint mode." In this mode, Perl inherently
distrusts any data that it receives from outside the program's source -- for example, data passed in
on the command line, read from a file, or taken from CGI parameters.

Tainted data cannot be used in
an expression that interacts with the outside world -- for example, you can't use it in a call to
system or as the name of a file to open. The full list of restrictions is given in the
perlsec manual page.

In order to use this data in any of these potentially dangerous operations you need to untaint it.
You do this by checking it against a regular expression. A detailed discussion of taint mode would
fill an article all by itself so I won't go into any more details here, but using taint mode is a very
good habit to get into -- particularly if you are writing programs (like CGI programs) that take
unknown input from users.

Providing a great GUI for complex routers or Linux admin is hard. Of course there has to be a CLI, that's how pros get the job
done. But a great GUI is one that teaches a new user to eventually graduate to using CLI.

Notable quotes:

"... Providing a great GUI for complex routers or Linux admin is hard. Of course there has to be a CLI, that's how pros get the job done. But a great GUI is one that teaches a new user to eventually graduate to using CLI. ..."

"... What would be nice is if the GUI could automatically create a shell script doing the change. That way you could (a) learn about how to do it per CLI by looking at the generated shell script, and (b) apply the generated shell script (after proper inspection, of course) to other computers. ..."

"... AIX's SMIT did this, or rather it wrote the commands that it executed to achieve what you asked it to do. This meant that you could learn: look at what it did and find out about which CLI commands to run. You could also take them, build them into a script, copy elsewhere, ... I liked SMIT. ..."

"... Cisco's GUI stuff doesn't really generate any scripts, but the commands it creates are the same things you'd type into a CLI. And the resulting configuration is just as human-readable (barring any weird naming conventions) as one built using the CLI. I've actually learned an awful lot about the Cisco CLI by using their GUI. ..."

"... Microsoft's more recent tools are also doing this. Exchange 2007 and newer, for example, are really completely driven by the PowerShell CLI. The GUI generates commands and just feeds them into PowerShell for you. So you can again issue your commands through the GUI, and learn how you could have done it in PowerShell instead. ..."

"... Moreover, the GUI authors seem to have a penchant to find new names for existing CLI concepts. Even worse, those names are usually inappropriate vagueries quickly cobbled together in an off-the-cuff afterthought, and do not actually tell you where the doodad resides in the menu system. With a CLI, the name of the command or feature set is its location. ..."

"... I have a cheap router with only a web gui. I wrote a two line bash script that simply POSTs the right requests to URL. Simply put, HTTP interfaces, especially if they implement the right response codes, are actually very nice to script. ..."

Deep End's Paul Venezia speaks out against the
overemphasis on GUIs in today's admin tools,
saying that GUIs are fine and necessary in many cases, but only after a complete CLI is in place, and that they cannot interfere
with the use of the CLI, only complement it. Otherwise, the GUI simply makes easy things easy and hard things much harder. He writes,
'If you have to make significant, identical changes to a bunch of Linux servers, is it easier to log into them one-by-one and run
through a GUI or text-menu tool, or write a quick shell script that hits each box and either makes the changes or simply pulls down
a few new config files and restarts some services? And it's not just about conservation of effort - it's also about accuracy. If
you write a script, you're certain that the changes made will be identical on each box. If you're doing them all by hand, you aren't.'"

Providing a great GUI for complex routers or Linux admin is hard. Of course there has to be a CLI, that's how pros get
the job done. But a great GUI is one that teaches a new user to eventually graduate to using CLI.

A bad GUI with no CLI is the worst of both worlds, the author of the article got that right. The 80/20 rule applies: 80% of
the work is common to everyone, and should be offered with a GUI. And the 20% that is custom to each sysadmin, well use the CLI.

maxwell demon:

What would be nice is if the GUI could automatically create a shell script doing the change. That way you could (a) learn
about how to do it per CLI by looking at the generated shell script, and (b) apply the generated shell script (after proper inspection,
of course) to other computers.

0123456 (636235) writes:

What would be nice is if the GUI could automatically create a shell script doing the change.

While it's not quite the same thing, our GUI-based home router has an option to download the config as a text file so you can
automatically reconfigure it from that file if it has to be reset to defaults. You could presumably use sed to change IP addresses,
etc, and copy it to a different router. Of course it runs Linux.

Alain Williams:

AIX's SMIT did this, or rather it wrote the commands that it executed to achieve what you asked it to do. This meant that
you could learn: look at what it did and find out about which CLI commands to run. You could also take them, build them into a
script, copy elsewhere, ... I liked SMIT.

Ephemeriis:

What would be nice is if the GUI could automatically create a shell script doing the change. That way you could (a) learn
about how to do it per CLI by looking at the generated shell script, and (b) apply the generated shell script (after proper inspection,
of course) to other computers.

Cisco's GUI stuff doesn't really generate any scripts, but the commands it creates are the same things you'd type into
a CLI. And the resulting configuration is just as human-readable (barring any weird naming conventions) as one built using the
CLI. I've actually learned an awful lot about the Cisco CLI by using their GUI.

We've just started working with Aruba hardware. Installed a mobility controller last week. They've got a GUI that does something
similar. It's all a pretty web-based front-end, but it again generates CLI commands and a human-readable configuration. I'm still
very new to the platform, but I'm already learning about their CLI through the GUI. And getting work done that I wouldn't be able
to if I had to look up the CLI commands for everything.

Microsoft's more recent tools are also doing this. Exchange 2007 and newer, for example, are really completely driven by
the PowerShell CLI. The GUI generates commands and just feeds them into PowerShell for you. So you can again issue your commands
through the GUI, and learn how you could have done it in PowerShell instead.

Anpheus:

Just about every Microsoft tool newer than 2007 does this. Virtual machine manager, SQL Server has done it for ages, I think
almost all the system center tools do, etc.

It's a huge improvement.

PoV:

All good admins document their work (don't they? DON'T THEY?). With a CLI or a script that's easy: it comes down to "log in
as user X, change to directory Y, run script Z with arguments A B and C - the output should look like D". Try that when all you
have is a GLUI (like a GUI, but you get stuck): open this window, select that option, drag a slider, check these boxes, click
Yes, three times. The output might look a little like this blurry screen shot and the only record of a successful execution is
a window that disappears as soon as the application ends.

I suppose the Linux community should be grateful that windows made the fundemental systems design error of making everything
graphic. Without that basic failure, Linux might never have even got the toe-hold it has now.

skids:

I think this is a stronger point than the OP: GUIs do not lead to good documentation. In fact, GUIs pretty much are limited
to procedural documentation like the example you gave.

The best they can do as far as actual documentation, where the precise effect of all the widgets is explained, is a screenshot
with little quote bubbles pointing to each doodad. That's a ridiculous way to document.

This is as opposed to a command reference which can organize, usually in a pretty sensible fashion, exact descriptions of what
each command does.

Moreover, the GUI authors seem to have a penchant to find new names for existing CLI concepts. Even worse, those names
are usually inappropriate vagueries quickly cobbled together in an off-the-cuff afterthought, and do not actually tell you where
the doodad resides in the menu system. With a CLI, the name of the command or feature set is its location.

Not that even good command references are mandatory by today's pathetic standards. Even the big boys like Cisco have shown
major degradation in the quality of their documentation during the last decade.

pedantic bore:

I think the author might not fully understand who most admins are. They're people who couldn't write a shell script if their
lives depended on it, because they've never had to. GUI-dependent users become GUI-dependent admins.

As a percentage of computer users, people who can actually navigate a CLI are an ever-diminishing group.

At least they named it NetworkManager, so experienced admins could recognize it as a culprit. Anything named in CamelCase is
almost invariably written by new school programmers who don't grok the Unix toolbox concept and write applications instead of
tools, and the bloated drivel is usually best avoided.

There are more and more small businesses (5, 10 or so employees) realizing that they can get things done easier if they had
a server. Because the business can't really afford to hire a sysadmin or a full-time tech person, its generally the employee who
"knows computers" (you know, the person who has to help the boss check his e-mail every day, etc.) and since they don't have the
knowledge of a skilled *Nix admin, a GUI makes their administration a lot easier.

So with the increasing use of servers among non-admins, it only makes sense for a growth in GUI-based solutions.

Svartalf (2997) writes: Ah... But the thing is... You don't NEED the GUI with recent Linux systems- you do with Windows.

Bingo. Realistically, if you're a company with less than a 100 employees (read: most companies), you're only going to have
a handful of servers in house and they're each going to be dedicated to particular roles. You're not going to have 100 clustered
fileservers - instead, you're going to have one or maybe two. You're not going to have a dozen e-mail servers - instead, you're
going to have one or two. Consequently, the office admin's focus isn't going to be scalability; it just won't matter to the admin
if they can script, say, creating a mailbox for 100 new users instead of just one. Instead, said office admin is going to be more
focused on finding ways to do semi-unusual things (e.g. "create a VPN between this office and our new branch office", "promote
this new server as a domain controller", "install SQL", etc.) that they might do, oh, once a year.

The trouble with Linux, and I'm speaking as someone who's used YaST in precisely this context, is that you have to make a choice
- do you let the GUI manage it or do you CLI it? If you try to do both, there will be inconsistencies because the grammar of the
config files is too ambiguous; consequently, the GUI config file parser will probably just overwrite whatever manual changes it
thinks is "invalid", whether it really is or not. If you let the GUI manage it, you better hope the GUI has the flexibility necessary
to meet your needs. If, for example, YaST doesn't understand named Apache virtual hosts, well, good luck figuring out where it's
hiding all of the various config files that it was sensibly spreading out in multiple locations for you, and don't you dare use
YaST to manage Apache again or it'll delete your Apache-legal but YaST-"invalid" directive.

The only solution I really see is for manual config file support with optional XML (or some other machine-friendly but still
human-readable format) linkages. For example, if you want to hand-edit your resolv.conf, that's fine, but if the GUI is going
to take over, it'll toss a directive on line 1 that says "#import resolv.conf.xml" and immediately overrides (but does not overwrite)
everything following that. Then, if you still want to use the GUI but need to hand-edit something, you can edit the XML file using
the appropriate syntax and know that your change will be reflected on the GUI.

I have a cheap router with only a web gui. I wrote a two line bash script that simply POSTs the right requests to URL.
Simply put, HTTP interfaces, especially if they implement the right response codes, are actually very nice to script.

devent (1627873) writes:

Why Windows servers have a GUI is beyond me anyway. The servers are running 99,99% of the time without a monitor and normally
you just login per ssh to a console if you need to administer them. But they are consuming the extra RAM, the extra CPU cycles
and the extra security threats. I don't now, but can you de-install the GUI from a Windows server? Or better, do you have an option
for no-GUI installation? Just saw the minimum hardware requirements. 512 MB RAM and 32 GB or greater disk space. My server runs

sirsnork (530512) writes: on Monday October 04, @07:43PM (#33789672)

it's called a "core" install in Server 2008 and up, and if you do that, there is no going back, you can't ever add the GUI
back.

What this means is you can run a small subset of MS services that don't need GUI interaction. With R2 that subset grew somwhat
as they added the ability to install .Net too, which mean't you could run IIS in a useful manner (arguably the strongest reason
to want to do this in the first place).

Still it's a one way trip and you better be damn sure what services need to run on that box for the lifetime of that box or
you're looking at a reinstall. Most windows admins will still tell you the risk isn't worth it.

Simple things like network configuration without a GUI in windows is tedious, and, at least last time i looked, you lost the
ability to trunk network poers because the NIC manufactuers all assumed you had a GUI to configure your NICs

This is also a problem with Max OS X Server. Apple builds their services from open source products and adds a GUI for configuration
to make it all clickable and easy to set up. However, many options that can be set on the command line can't be set in the GUI.
Even worse, making CLI changes to services can break the GUI entirely.

The hardware and software are both super stable and run really smoothly, so once everything gets set up, it's awesome. Still,
it's hard for a guy who would rather make changes on the CLI to get used to.

MrEricSir (398214) writes:

Just because you're used to a CLI doesn't make it better. Why would I want to read a bunch of documentation, mess with command
line options, then read whole block of text to see what it did? I'd much rather sit back in my chair, click something, and then
see if it worked. Don't make me read a bunch of man pages just to do a simple task. In essence, the question here is whether it's
okay for the user to be lazy and use a GUI, or whether the programmer should be too lazy to develop a GUI.

How do you troubleshoot something with a GUI after you've misconfigured? How do you troubleshoot a programming error (bug)
in the GUI -> device communication? How do you scale to tens, hundreds, or thousands of devices with a GUI?

CLI makes all this easier and more manageable.

arth1 (260657) writes:

Why would I want to read a bunch of documentation, mess with command line options, then read whole block of text to see what
it did? I'd much rather sit back in my chair, click something, and then see if it worked. Don't make me read a bunch of man pages
just to do a simple task. Because then you'll be stuck at doing simple tasks, and will never be able to do more advanced tasks.
Without hiring a team to write an app for you instead of doing it yourself in two minutes, that is. The time you spend reading
man

fandingo (1541045) writes: on Monday October 04, @07:54PM (#33789778)

I don't think you really understand systems administration. 'Users,' or in this case admins, don't typically do stuff once.
Furthermore, they need to know what he did and how to do it again (i.e. new server or whatever) or just remember what he did.
One-off stuff isn't common and is a sign of poor administration (i.e. tracking changes and following processes).

What I'm trying to get at is that admins shouldn't do anything without reading the manual. As a Windows/Linux admin, I tend
to find Linux easier to properly administer because I either already know how to perform an operation or I have to read the manual
(manpage) and learn a decent amount about the operation (i.e. more than click here/use this flag).

Don't get me wrong, GUIs can make unknown operations significantly easier, but they often lead to poor process management.
To document processes, screenshots are typically needed. They can be done well, but I find that GUI documentation (created by
admins, not vendor docs) tend to be of very low quality. They are also vulnerable to 'upgrades' where vendors change the interface
design. CLI programs typically have more stable interfaces, but maybe that's just because they have been around longer...

That's one thing Microsoft did right with Exchange 2007. They built it entirely around their new powershell CLI and then built
a GUI for it. The GUI is limited in compared to what you can do with the CLI, but you can get most things done. The CLI becomes
extremely handy for batch jobs and exporting statistics to csv files. I'd say it's really up there with BASH in terms of scripting,
data manipulation, and integration (not just Exchange but WMI, SQL, etc.)

They tried to do similar with Windows 2008 and their Core [petri.co.il] feature, but they still have to load a GUI to present
a prompt...Reply to This

Probably Debian would have been OK, but I was finding admin of most Linux distros a pain for exactly these reasons.
I couldn't find a layer where I could do everything that I needed to do without worrying about one thing stepping on another.
No doubt there are ways that I could manage a Linux system without running into different layers of management tools stepping
on each other, but it was a struggle.

There were other reasons as well (although there is a lot that I miss about Linux), but I think that this was one of the leading
reasons.

(NB: I realize that this is flamebait (I've got karma to burn), but that isn't my intention here.)

Notable quotes:

"... Sometimes the old ways are best, and they're certainly worth knowing well ..."

As I write this column, I'm in the middle of two summer projects; with luck, they'll both be finished by the time you read it.

One involves a forensic analysis of over 100,000 lines of old C and assembly code from about 1990, and I have to work on Windows
XP.

The other is a hack to translate code written in weird language L1 into weird language L2 with a program written in scripting
language L3, where none of the L's even existed in 1990; this one uses Linux. Thus it's perhaps a bit surprising that I find myself
relying on much the same toolset for these very different tasks.

... ... ...

Here has surely been much progress in tools over the 25 years that IEEE Software has been around, and I wouldn't want to go back
in time.

But the tools I use today are mostly the same old ones-grep, diff, sort, awk, and friends. This might well mean that I'm a dinosaur
stuck in the past.

On the other hand, when it comes to doing simple things quickly, I can often have the job done while experts are still waiting
for their IDE to start up. Sometimes the old ways are best, and they're certainly worth knowing well

Notable quotes:

"... The conventional Simula 67-like pattern of class and instance will get you {1,3,7,9}, and I think many people take this as a definition of OO. ..."

"... Because OO is a moving target, OO zealots will choose some subset of this menu by whim and then use it to try to convince you that you are a loser. ..."

"... In such a pack-programming world, the language is a constitution or set of by-laws, and the interpreter/compiler/QA dept. acts in part as a rule checker/enforcer/police force. Co-programmers want to know: If I work with your code, will this help me or hurt me? Correctness is undecidable (and generally unenforceable), so managers go with whatever rule set (static type system, language restrictions, "lint" program, etc.) shows up at the door when the project starts. ..."

Here is an a la carte menu of features or properties that are related to these terms; I have heard OO defined to be many different
subsets of this list.

Encapsulation - the ability to syntactically hide the implementation of a type. E.g. in C or Pascal you always know
whether something is a struct or an array, but in CLU and Java you can hide the difference.

Protection - the inability of the client of a type to detect its implementation. This guarantees that a behavior-preserving
change to an implementation will not break its clients, and also makes sure that things like passwords don't leak out.

Ad hoc polymorphism - functions and data structures with parameters that can take on values of many different types.

Parametric polymorphism - functions and data structures that parameterize over arbitrary values (e.g. list of anything).
ML and Lisp both have this. Java doesn't quite because of its non-Object types.

Everything is an object - all values are objects. True in Smalltalk (?) but not in Java (because of int and friends).

All you can do is send a message (AYCDISAM) = Actors model - there is no direct manipulation of objects, only communication
with (or invocation of) them. The presence of fields in Java violates this.

Specification inheritance = subtyping - there are distinct types known to the language with the property that a value of
one type is as good as a value of another for the purposes of type correctness. (E.g. Java interface inheritance.)

Implementation inheritance/reuse - having written one pile of code, a similar pile (e.g. a superset) can be generated in
a controlled manner, i.e. the code doesn't have to be copied and edited. A limited and peculiar kind of abstraction. (E.g.
Java class inheritance.)

Sum-of-product-of-function pattern - objects are (in effect) restricted to be functions that take as first argument a distinguished
method key argument that is drawn from a finite set of simple names.

So OO is not a well defined concept. Some people (eg. Abelson and Sussman?) say Lisp is OO, by which they mean {3,4,5,7} (with
the proviso that all types are in the programmers' heads). Java is supposed to be OO because of {1,2,3,7,8,9}. E is supposed to be
more OO than Java because it has {1,2,3,4,5,7,9} and almost has 6; 8 (subclassing) is seen as antagonistic to E's goals and not necessary
for OO.

The conventional Simula 67-like pattern of class and instance will get you {1,3,7,9}, and I think many people take this as
a definition of OO.

Because OO is a moving target, OO zealots will choose some subset of this menu by whim and then use it to try to convince
you that you are a loser.

Perhaps part of the confusion - and you say this in a different way in your little
memo - is that the C/C++ folks see OO as a liberation from a world
that has nothing resembling a first-class functions, while Lisp folks see OO as a prison since it limits their use of functions/objects
to the style of (9.). In that case, the only way OO can be defended is in the same manner as any other game or discipline -- by arguing
that by giving something up (e.g. the freedom to throw eggs at your neighbor's house) you gain something that you want (assurance
that your neighbor won't put you in jail).

This is related to Lisp being oriented to the solitary hacker and discipline-imposing languages being oriented to social packs,
another point you mention. In a pack you want to restrict everyone else's freedom as much as possible to reduce their ability to
interfere with and take advantage of you, and the only way to do that is by either becoming chief (dangerous and unlikely) or by
submitting to the same rules that they do. If you submit to rules, you then want the rules to be liberal so that you have a chance
of doing most of what you want to do, but not so liberal that others nail you.

In such a pack-programming world, the language is a constitution or set of by-laws, and the interpreter/compiler/QA dept.
acts in part as a rule checker/enforcer/police force. Co-programmers want to know: If I work with your code, will this help me or
hurt me? Correctness is undecidable (and generally unenforceable), so managers go with whatever rule set (static type system, language
restrictions, "lint" program, etc.) shows up at the door when the project starts.

Value = something that can be passed to some function (abstraction). (I exclude exotic compile-time things like parameters
to macros and to parameterized types and modules.)

Object = a value that has function-like behavior, i.e. you can invoke a method on it or call it or send it a message
or something like that. Some people define object more strictly along the lines of 9. above, while others (e.g. CLTL) are more
liberal. This is what makes "everything is an object" a vacuous statement in the absence of clear definitions.

In some languages the "call" is curried and the key-to-method mapping can sometimes be done at compile time. This technicality
can cloud discussions of OO in C++ and related languages.

Function = something that can be combined with particular parameter(s) to produce some result. Might or might not be
the same as object depending on the language.

Type = a description of the space of values over which a function is meaningfully parameterized. I include both types
known to the language and types that exist in the programmer's mind or in documentation

As I write this column, I'm in the middle of two summer projects; with luck, they'll both be finished by the time you read it.

One involves a forensic analysis of over 100,000 lines of old C and assembly code from about 1990, and I have to work on Windows
XP.

The other is a hack to translate code written in weird language L1 into weird language L2 with a program written in scripting
language L3, where none of the L's even existed in 1990; this one uses Linux. Thus it's perhaps a bit surprising that I find myself
relying on much the same toolset for these very different tasks.

... ... ...

Here has surely been much progress in tools over the 25 years that IEEE Software has been around, and I wouldn't want to go back
in time.

But the tools I use today are mostly the same old ones-grep, diff, sort, awk, and friends. This might well mean that I'm a dinosaur
stuck in the past.

On the other hand, when it comes to doing simple things quickly, I can often have the job done while experts are still waiting
for their IDE to start up. Sometimes the old ways are best, and they're certainly worth knowing well

"... If there's something I've noticed in my career that is that there are always some guys that desperately want to look "smart" and they reflect that in their code. ..."

If there's something I've noticed in my career that is that there are always some guys that desperately want to look "smart"
and they reflect that in their code.

If there's something else that I've noticed in my career, it's that their code is the hardest to maintain and for some reason
they want the rest of the team to depend on them since they are the only "enough smart" to understand that code and change it.
No need to say that these guys are not part of my team. Your code should be direct, simple and readable. End of story.

"... If there's something I've noticed in my career that is that there are always some guys that desperately want to look "smart"
and they reflect that in their code. ..."

If there's something I've noticed in my career that is that there are always some guys that desperately want to look "smart"
and they reflect that in their code.

If there's something else that I've noticed in my career, it's that their code is the hardest to maintain and for some reason
they want the rest of the team to depend on them since they are the only "enough smart" to understand that code and change it.
No need to say that these guys are not part of my team. Your code should be direct, simple and readable. End of story.

To fairly review this book, one must distinguish between the methodology it presents and
the actual presentation. As to the presentation, the author attempts to win the reader over
with emotional persuasion and pep talk rather than with facts and hard evidence. Stories of
childhood and comradeship don't classify as convincing facts to me. A single case study-the
C3 project-is often referred to, but with no specific information (do note that the project
was cancelled by the client after staying in development for far too long).
As to the method itself, it basically boils down to four core practices:
1. Always have a customer available on site.
2. Unit test before you code.
3. Program in pairs.
4. Forfeit detailed design in favor of incremental, daily releases and refactoring.
If you do the above, and you have excellent staff on your hands, then the book promises that
you'll reap the benefits of faster development, less overtime, and happier customers. Of
course, the book fails to point out that if your staff is all highly qualified people, then
the project is likely to succeed no matter what methodology you use. I'm sure that anyone who
has worked in the software industry for sometime has noticed the sad state that most computer
professionals are in nowadays.
However, assuming that you have all the topnotch developers that you desire, the outlined
methodology is almost impossible to apply in real world scenarios. Having a customer always
available on site would mean that the customer in question is probably a small, expendable
fish in his organization and is unlikely to have any useful knowledge of its business
practices. Unit testing code before it is written means that one would have to have a mental
picture of what one is going to write before writing it, which is difficult without upfront
design. And maintaining such tests as the code changes would be a nightmare. Programming in
pairs all the time would assume that your topnotch developers are also sociable creatures,
which is rarely the case, and even if they were, no one would be able to justify the practice
in terms of productivity. I won't discuss why I think that abandoning upfront design is a bad
practice; the whole idea is too ridiculous to debate.
Both book and methodology will attract fledgling developers with its promise of hacking as an
acceptable software practice and a development universe revolving around the programmer. It's
a cult, not a methodology, were the followers shall find salvation and 40-hour working weeks.
Experience is a great teacher, but only a fool would learn from it alone. Listen to what the
opponents have to say before embracing change, and don't forget to take the proverbial grain
of salt.
Two stars out of five for the presentation for being courageous and attempting to defy the
standard practices of the industry. Two stars for the methodology itself, because it
underlines several common sense practices that are very useful once practiced without the
extremity.

Maybe it's an interesting idea, but it's just not ready for prime time.
Parts of Kent's recommended practice - including aggressive testing and short integration
cycle - make a lot of sense. I've shared the same beliefs for years, but it was good to see
them clarified and codified. I really have changed some of my practice after reading this and
books like this.
I have two broad kinds of problem with this dogma, though. First is the near-abolition of
documentation. I can't defend 2000 page specs for typical kinds of development. On the other
hand, declaring that the test suite is the spec doesn't do it for me either. The test suite
is code, written for machine interpretation. Much too often, it is not written for human
interpretation. Based on the way I see most code written, it would be a nightmare to reverse
engineer the human meaning out of any non-trivial test code. Some systematic way of ensuring
human intelligibility in the code, traceable to specific "stories" (because "requirements"
are part of the bad old way), would give me a lot more confidence in the approach.
The second is the dictatorial social engineering that eXtremity mandates. I've actually tried
the pair programming - what a disaster. The less said the better, except that my experience
did not actually destroy any professional relationships. I've also worked with people who
felt that their slightest whim was adequate reason to interfere with my work. That's what
Beck institutionalizes by saying that any request made of me by anyone on the team must be
granted. It puts me completely at the mercy of anyone walking by. The requisite bullpen
physical environment doesn't work for me either. I find that the visual and auditory
distraction make intense concentration impossible.
I find revival tent spirit of the eXtremists very off-putting. If something works, it works
for reasons, not as a matter of faith. I find much too much eXhortation to believe, to go
ahead and leap in, so that I will eXperience the wonderfulness for myself. Isn't that what
the evangelist on the subway platform keeps saying? Beck does acknowledge unbelievers like
me, but requires their exile in order to maintain the group-think of the X-cult.
Beck's last chapters note a number of exceptions and special cases where eXtremism may not
work - actually, most of the projects I've ever encountered.
There certainly is good in the eXtreme practice. I look to future authors to tease that good
out from the positively destructive threads that I see interwoven.

By A customer on May 2, 2004

A work of fiction

The book presents extreme programming. It is divided into three parts:
(1) The problem
(2) The solution
(3) Implementing XP.
The problem, as presented by the author, is that requirements change but current
methodologies are not agile enough to cope with this. This results in customer being unhappy.
The solution is to embrace change and to allow the requirements to be changed. This is done
by choosing the simplest solution, releasing frequently, refactoring with the security of
unit tests.
The basic assumption which underscores the approach is that the cost of change is not
exponential but reaches a flat asymptote. If this is not the case, allowing change late in
the project would be disastrous. The author does not provide data to back his point of view.
On the other hand there is a lot of data against a constant cost of change (see for example
discussion of cost in Code Complete). The lack of reasonable argumentation is an irremediable
flaw in the book. Without some supportive data it is impossible to believe the basic
assumption, nor the rest of the book. This is all the more important since the only project
that the author refers to was cancelled before full completion.
Many other parts of the book are unconvincing. The author presents several XP practices. Some
of them are very useful. For example unit tests are a good practice. They are however better
treated elsewhere (e.g., Code Complete chapter on unit test). On the other hand some
practices seem overkill. Pair programming is one of them. I have tried it and found it useful
to generate ideas while prototyping. For writing production code, I find that a quiet
environment is by far the best (see Peopleware for supportive data). Again the author does
not provide any data to support his point.
This book suggests an approach aiming at changing software engineering practices. However the
lack of supportive data makes it a work of fiction.
I would suggest reading Code Complete for code level advice or Rapid Development for
management level advice.

By A customer on November 14, 2002

Not Software Engineering.

Any Engineering discipline is based on solid reasoning and logic not on blind faith.
Unfortunately, most of this book attempts to convince you that Extreme programming is better
based on the author's experiences. A lot of the principles are counter - intutive and the
author exhorts you just try it out and get enlightened. I'm sorry but these kind of things
belong in infomercials not in s/w engineering.
The part about "code is the documentation" is the scariest part. It's true that keeping the
documentation up to date is tough on any software project, but to do away with dcoumentation
is the most ridiculous thing I have heard. It's like telling people to cut of their noses to
avoid colds.
Yes we are always in search of a better software process. Let me tell you that this book
won't lead you there.

This book reminds me of the "gossip magazine diet plans", you know, the vinegar and honey
diet, or the fat-burner 2000 pill diet etc. Occasionally, people actually lose weight on
those diets, but, only because they've managed to eat less or exercise more. The diet plans
themselves are worthless. XP is the same - it may sometimes help people program better, but
only because they are (unintentionally) doing something different. People look at things like
XP because, like dieters, they see a need for change. Overall, the book is a decently written
"fad diet", with ideas that are just as worthless.

By A customer on August 11, 2003

Hackers! Salvation is nigh!!

It's interesting to see the phenomenon of Extreme Programming happening in the dawn of the
21st century. I suppose historians can explain such a reaction as a truly conservative
movement. Of course, serious software engineering practice is hard. Heck, documentation is a
pain in the neck. And what programmer wouldn't love to have divine inspiration just before
starting to write the latest web application and so enlightened by the Almighty, write the
whole thing in one go, as if by magic? No design, no documentation, you and me as a pair, and
the customer too. Sounds like a hacker's dream with "Imagine" as the soundtrack (sorry,
John).
The Software Engineering struggle is over 50 years old and it's only logical to expect some
resistance, from time to time. In the XP case, the resistance comes in one of its worst
forms: evangelism. A fundamentalist cult, with very little substance, no proof of any kind,
but then again if you don't have faith you won't be granted the gift of the mystic
revelation. It's Gnosticism for Geeks.
Take it with a pinch of salt.. well, maybe a sack of salt. If you can see through the B.S.
that sells millions of dollars in books, consultancy fees, lectures, etc, you will recognise
some common-sense ideas that are better explained, explored and detailed elsewhere.

Kent is an excellent writer. He does an excellent job of presenting an approach to
software development that is misguided for anything but user interface code. The argument
that user interface code must be gotten into the hands of users to get feedback is used to
suggest that complex system code should not be "designed up front". This is simply wrong. For
example, if you are going to deply an application in the Amazon Cloud that you want to scale,
you better have some idea of how this is going to happen. Simply waiting until you
application falls over and fails is not an acceptable approach.

One of the things I despise the most about the software development culture is the
mindless adoption of fads. Extreme programming has been adopted by some organizations like a
religious dogma.

Engineering large software systems is one of the most difficult things that humans do.
There are no silver bullets and there are no dogmatic solutions that will make the difficult
simple.

Maybe I'm too cynical because I never got to work for the successful, whiz-kid companies;
Maybe this book wasn't written for me!

This book reminds me of Jacobsen's "Use Cases" book of the 1990s. 'Use Cases' was all the
rage but after several years, we slowly learned the truth: Uses Cases does not deal with the
architecture - a necessary and good foundation for any piece of software.

Similarly, this book seems to be spotlighting Testing and taking it to extremes.

'the test plan is the design doc'

Not True. The design doc encapsulates wisdom and insight

a picture that accurately describes the interactions of the lower level software
components is worth a thousand lines of code-reading.

Also present is an evangelistic fervor that reminds me of the rah-rah eighties'
bestseller, "In Search Of Excellence" by Peters and Waterman. (Many people have since noted
that most of the spotlighted companies of that book are bankrupt twenty five years
later).

- in a room full of people with a bully supervisor (as I experienced in my last job at a
major telco) innovation or good work is largely absent.

- deploy daily - are you kidding?

to run through the hundreds of test cases in a large application takes several hours if
not days. Not all testing can be automated.

- I have found the principle of "baby steps", one of the principles in the book, most
useful in my career - it is the basis for prototyping iteratively. However I heard it
described in 1997 at a pep talk at MCI that the VP of our department gave to us. So I dont
know who stole it from whom!

Lastly, I noted that the term 'XP' was used throughout the book, and the back cover has a
blurb from an M$ architect. Was it simply coincidence that Windows shares the same name for
its XP release? I wondered if M$ had sponsored part of the book as good advertising for
Windows XP! :)

Notable quotes:

"... This article originally appeared on Alice, Eve, and Bob – a security blog and is republished with permission. ..."

Review by many eyes does not always prevent buggy codeThere is a view that
because open source software is subject to review by many eyes, all the bugs will be ironed out
of it. This is a myth. 06 Oct 2017 Mike Bursell (Red Hat)Feed 8
up Image credits :
Internet Archive Book Images . CC BY-SA 4.0 Writing code is hard.
Writing secure code is harder -- much harder. And before you get there, you need to think about
design and architecture. When you're writing code to implement security functionality, it's
often based on architectures and designs that have been pored over and examined in detail. They
may even reflect standards that have gone through worldwide review processes and are generally
considered perfect and unbreakable. *

However good those designs and architectures are, though, there's something about putting
things into actual software that's, well, special. With the exception of software proven to be
mathematically correct, ** being able to write software
that accurately implements the functionality you're trying to realize is somewhere between a
science and an art. This is no surprise to anyone who's actually written any software, tried to
debug software, or divine software's correctness by stepping through it; however, it's not the
key point of this article.

Nobody *** actually believes that the
software that comes out of this process is going to be perfect, but everybody agrees that
software should be made as close to perfect and bug-free as possible. This is why code review
is a core principle of software development. And luckily -- in my view, at least -- much of the
code that we use in our day-to-day lives is open source, which means that anybody can look at
it, and it's available for tens or hundreds of thousands of eyes to review.

And herein lies the problem: There is a view that because open source software is subject to
review by many eyes, all the bugs will be ironed out of it. This is a myth. A dangerous myth.
The problems with this view are at least twofold. The first is the "if you build it, they will
come" fallacy. I remember when there was a list of all the websites in the world, and if you
added your website to that list, people would visit it. **** In the same way, the
number of open source projects was (maybe) once so small that there was a good chance that
people might look at and review your code. Those days are past -- long past. Second, for many
areas of security functionality -- crypto primitives implementation is a good example -- the
number of suitably qualified eyes is low.

Don't think that I am in any way suggesting that the problem is any less in proprietary
code: quite the opposite. Not only are the designs and architectures in proprietary software
often hidden from review, but you have fewer eyes available to look at the code, and the
dangers of hierarchical pressure and groupthink are dramatically increased. "Proprietary code
is more secure" is less myth, more fake news. I completely understand why companies like to
keep their security software secret, and I'm afraid that the "it's to protect our intellectual
property" line is too often a platitude they tell themselves when really, it's just unsafe to
release it. So for me, it's open source all the way when we're looking at security
software.

So, what can we do? Well, companies and other organizations that care about security
functionality can -- and have, I believe a responsibility to -- expend resources on checking
and reviewing the code that implements that functionality. Alongside that, the open source
community, can -- and is -- finding ways to support critical projects and improve the amount of
review that goes into that code. ***** And we should encourage
academic organizations to train students in the black art of security software writing and
review, not to mention highlighting the importance of open source software.

We can do better -- and we are doing better. Because what we need to realize is that the
reason the "many eyes hypothesis" is a myth is not that many eyes won't improve code -- they
will -- but that we don't have enough expert eyes looking. Yet.

* Yeah, really: "perfect and unbreakable." Let's just pretend that's true
for the purposes of this discussion.

** and that still relies on the design and architecture to actually do what
you want -- or think you want -- of course, so good luck.

*** Nobody who's actually written more than about five lines of code (or
more than six characters of Perl).

(acolyer.org) Posted by EditorDavid on Saturday September 23, 2017 @05:19PM from the
dynamic-discussions dept. "Static vs dynamic typing is always one of those topics that attracts
passionately held positions," writes the Morning Paper -- reporting on an "encouraging" study that attempted
to empirically evaluate the efficacy of statically-typed systems on mature, real-world code
bases. The study was conducted by Christian Bird at Microsoft's "Research in Software
Engineering" group with two researchers from University College London. Long-time Slashdot
reader phantomfive writes:
This study looked at bugs found in open source Javascript code. Looking through the commit
history, they
enumerated the bugs that would have been caught if a more strongly typed language (like
Typescript) had been used. They found that a strongly typed language would have reduced bugs by
15%. Does this make you want to avoid Python?

BrianFagioli shares a report from
BetaNews: The documentation aspect of any project is very important, as it can help people to
both understand it and track changes. Unfortunately, many developers aren't very interested in documentation
aspect, so it often gets neglected. Luckily, if you want to maintain proper documentation and stay
organized, today, Google is
releasing
its internal developer documentation style guide .

This can quite literally guide your documentation,
giving you a great starting point and keeping things consistent. Jed Hartman, Technical Writer, Google
says , "For some years now, our technical writers at Google have used an internal-only editorial
style guide for most of our developer documentation. In order to better support external contributors
to our open source projects, such as Kubernetes, AMP, or Dart, and to allow for more consistency
across developer documentation, we're now making that style guide public.

If you contribute documentation
to projects like those, you now have direct access to useful guidance about voice, tone, word choice,
and other style considerations. It can be useful for general issues, like reminders to use second
person, present tense, active voice, and the serial comma; it can also be great for checking very
specific issues, like whether to write 'app' or 'application' when you want to be consistent with
the Google Developers style."

Of course, everybody knows that you should always leverage other people's work. The correct
answers are, of course, 1(a) 2(b) 3(b).

Right?

Not so fast, there!

The Not-Invented-Here Syndrome is considered a classic management pathology, in which a team refuses
to use a technology that they didn't create themselves. People with NIH
syndrome are obviously just being petty, refusing to do what's in the best interest
of the overall organization because they can't find a way to take credit. (Right?) The Boring Business
History Section at your local megabookstore is rife with stories about stupid teams that spend millions
of dollars and twelve years building something they could have bought at Egghead for $9.99. And everybody
who has paid any attention whatsoever to three decades of progress in computer programming
knows that Reuse is the Holy Grail of all modern programming systems.

Right. Well, that's what I thought, too. So when I was the program manager in charge of the first
implementation of Visual Basic for Applications, I put together a careful coalition of four, count
them, four different teams at Microsoft to get custom dialog boxes in Excel VBA. The idea was complicated
and fraught with interdependencies. There was a team called AFX that was working on some kind of
dialog editor. Then we would use this brand new code from the OLE group which let you embed one app
inside another. And the Visual Basic team would provide the programming language behind it. After
a week of negotiation I got the AFX, OLE, and VB teams to agree to this in principle.

I stopped by Andrew Kwatinetz's office. He was my manager at the time and taught me everything
I know. "The Excel development team will never accept it," he said. "You know their motto? 'Find
the dependencies -- and eliminate them.' They'll never go for something
with so many dependencies."

In-ter-est-ing. I hadn't known that. I guess that explained why Excel had its ownC compiler.

By now I'm sure many of my readers are rolling on the floor laughing. "Isn't Microsoft stupid,"
you're thinking, "they refused to use other people's code and they even had their own compiler just
for one product."

Not so fast, big boy! The Excel team's ruggedly independent mentality also meant that they always
shipped on time, their code was of uniformly high quality, and they had a compiler which, back in
the 1980s, generated pcode and could therefore run unmodified on Macintosh's 68000 chip as well as
Intel PCs. The pcode also made the executable file about half the size that Intel binaries would
have been, which loaded faster from floppy disks and required less RAM.

"Find the dependencies -- and eliminate them." When you're working on a really, really good team
with great programmers, everybody else's code, frankly, is bug-infested garbage, and nobody else
knows how to ship on time. When you're a cordon bleu chef and you need fresh lavender, you
grow it yourself instead of buying it in the farmers' market, because sometimes they don't have fresh
lavender or they have old lavender which they pass off as fresh.

This paper provides one review of the comparative strengths and weaknesses
of LOCC and
CodeCount, two
tools for calculating the size of software source code. The next two sections provide quick overviews
of CodeCount and LOCC. The final section presents the perceived strengths and weaknesses of the two
tools. A caveat: although I am attempting to be objective in this review, I have in-depth knowledge
of LOCC and only very superficial knowledge of CodeCount. Comments and corrections solicited and
welcomed.

CodeCount

The incarnations of CodeCount can be divided into two basic flavors.
The first flavor, which I will dub as "Classic" CodeCount, has been in production use for over a
decade. The second flavor, dubbed "CSCI" CodeCount, is the result of a set of student projects to
support various "object" languages by extending Classic CodeCount.

Classic CodeCount is a relatively old and mature project. The first
work on Classic CodeCount began in the late 1980's. CodeCount reflects its early origins in three
important ways.

It is written in ANSI C, with all the typical strengths (speed)
and weaknesses (lack of higher level program structuring mechanisms, etc.) of that language.

It was originally designed to provide size metric information
appropriate to the kinds of languages targetted at that time (assembly languages and non-OO languages
such as C and Fortran). Classic CodeCount does not employ a grammar and so has cannot reliably
recognize object oriented language structures within a file, such as packages, classes, methods,
inner classes, etc.

It has been used extensively by many industrial partners for over
a decade, and has presumably been used to count many millions of lines of code. It can be presumed
to be well-tested and reliable for the kinds of measures it produces.

The CodeCount toolset is a collection of tools designed to automate the collection
of source code sizing information. The CodeCount toolset spans multiple programming languages and
utilizes one of two possible Source Lines of Code (SLOC) definitions, physical or logical. CODECount's
license is not Libre Software as it puts additional restrictions.

The cflow command analyzes the C, C++, yacc, lex, assembler, and object files and
writes a chart of their external references to standard output.
Cflow2vcg converts the result of the
cflow utility to a VCG format. See also
Cflow2Cflow

perl-metrics is intended to help perl programmers write better code by helping
programmers become more aware of their coding style. In particular, one would like to know the code-to-comment
ratio, the average number of lines per subroutine, and the longest subroutine.

Pythius is a set of tools to assess the quality of Python code. This is commonly
done by applying different code metrics. Simple code metrics are the ratio between comments and code
lines, module and function size, etc.

This page offers access to a collection of static code analysis tools that compute
various metrics defined on C and C++ source code. The metrics are primarily size and complexity of
various types (lines of code, Halstead, McCabe, etc.).

Was first published in 1979. Now slightly outdated.
Code Complete : A Practical Handbook of Software Construction contains similar material if
you want a more recent book, but this book pioneered the field. Contains an interesting discussion
of how to transform the program to a better one and common pitfalls in programming. The authors have
provided an useful set of tips for coding (and sometimes design). Here is a summary of the important
programming style tips from Brian Kernighan's 1994 guest CS50 lecture:

Say what you mean, simply and directly.

Use the "telephone test'' for readability.

Write clearly - don't be too clever.

Don't use conditional expressions as a substitute for a logical expression.

Parenthesize to avoid ambiguity.

Each time you make a test, do something.

Follow each decision as closely as possible with its associated action.

The success or failure of any software programming group depends largely on its ability
to work together as a team. From manager to members, to well-conceived, yet dynamic guidelines,
the team as a whole is defined by the unison of its parts. Shattering the myth of the faultless
programmer, Teodor dismantles the uninspired software group and then builds it up again into
a synchronized, energized ensemble.

Welcome to a series of articles on developerWorks comprising a complete guide to better programming
in Perl. In this first installment, Teodor introduces his book and looks at coding guidelines
from a fresh perspective.

This is the book for the beginner to intermediate Perl programmer. But even an advanced Perl
programmer can find the majority of the chapters exciting and relevant, from the tips of Part
I to the project management tools presented in Part II to the Parse::RecDescentsource
code analysis scripts in Part III.

The words program and
script are used interchangeably.
In Perl, the two mean pretty much the same thing. A program can, indeed, be made up of many scripts,
and a script can contain many programs, but for simplicity's sake, we will use the two terms with
the understanding that one script file contains only one program.

Part I is full of tips to improve
your Perl skills, ranging from best programming practices to code debugging. It does not teach
you Perl programming. There are many books with that purpose, and they would be hard to surpass
in clarity and completeness.

Part II will teach you how a small
Perl software team can be better managed with the standard tools of software project management.
Often, Perl programmers embody the "herd of cats" view of software teams. Part II will apply project
management tools to a small (2- to 6-person) Perl development team, and will examine how managing
such a team successfully is different from the classic project management approach.

Part III will develop tools to
analyze source code (Perl and C examples will be developed) and to help you manage your team better.
Analysis of source code is superficial at best today, ranging from the obvious and irrelevant
"lines of code" metrics to function points (see
Resources
later in this article), which do not help in understanding the programmer's mindset. Understanding
the programmer's mindset will be the goal of Part III. Tools will be developed that help track
metrics such as comment legibility and consistency, repetitiveness of code, and code legibility.
These metrics will be introduced as a part of a software project, not its goal.

There is no perfection in programming, only its pursuit. Good programmers learn something new
every day and continually improve their skills and technique. Rigidity and inflexibility are forever
the enemy of ingenuity and creativity.

The most common mistake a programmer can make is not in the list of bugs for his program. It
is not a function of the programmer's age or language of choice. It is, simply, the assumption
that his abilities are complete and there is
no room for improvement.

Arguably, such is human nature; but I would argue that human nature is always on the prowl
for knowledge and improvement. Only hubris and the fear of being proven wrong hold us back. Resisting
them both will not only make a better programmer, but a better person as well.

The social interactions and the quality of the people, I believe, are what create successful
software teams more than any other factors. Constant improvement in a programmer's skills and
the ability to take criticism are fundamental requirements for members of a software team. These
requirements should precede all others.

Think back to the last time you changed your style. Was it the new algorithm you learned, or
commenting style, or simply a different way of naming your variables? Whatever it was, it was
only a step along the way, not the final change that made your code complete and perfect.

A programmer shouldn't be required to follow precise code guidelines to the letter; nor should
he improvise those guidelines to get the job done. Consider an orchestra -- neither static, soulless
performers nor wildly improvisational virtuosos (though the latter is more acclaimed). A static
performer simply follows the notes without putting effort and soul into the music; the virtuoso
must restrain herself from errantly exploring new pieces of the melody or marching to the beat
of her own drum.

Striking a concordant tone
Code guidelines are like the written directions a musician follows -- when to come on, when to
come off, how fast to play, what beat, etc. The notes themselves, to extend the analogy somewhat
precariously, are the goals of the project -- sometimes lone high notes, and sometimes a harmony
of instruments.

In an orchestra, there is a conductor that directs but does not tell every musician how to
play, and everyone has a part in the performance. The conductor creates harmony. Because music
has been around for many more centuries than the art of programming, perhaps these are lessons
well worth learning. The software project manager is neither a gorilla nor a walled-off convict.
She is a part of the team just like everyone else.

The guidelines presented in this series are not to be blindly extracted into an official coding
policy. The coding standards in your project are uniquely yours, and they reflect your very own
orchestral composition. Don't force programmers to do things exactly right, thereby creating an
atmosphere of distrust and fear. You can forget about code reviews, or admission of responsibility
for the smallest bugs.

Instead, present the guidelines and watch how people react. If no one adopts the comment format
you like, perhaps it's a bad format. If people write without cleverness, perhaps you have been
too clever in the guidelines. If the debugger you thought everyone must run is sitting in a dusty
room, still packed, then rethink the need for Whizzo Debugger 3.4. Maybe everyone is happy with
Acme Debugger 1.0 for a reason.

Of course, programmers can be stubborn for no reason at all, only out of reluctance to change.
It's hard to convince people that 20 years of experience do not entitle them to an organized religion.
On the other hand, freshly minted college graduates often lack self-confidence. Recognize and
adapt to those characteristics, and to all the others of your team. Present ideas to the stubbornly
experienced in such a way that they feel they have helped with it. Build up the college graduates
with guidance and support until they can fly on their own.

All this, just for a few coding guidelines?
Coding guidelines are fundamental to a software team, just as direction and harmony are to music.
They create consistency and cohesiveness. New team members will feel welcome and gel more quickly.
Ye olde team members will accept newcomers more readily. The loss of a team member will not cripple
the project just because someone can't understand someone else's code.

Keep in mind that speed is not the only measure of improvement in a program's code. Consider
ease of testing, documentation, and maintenance just as important to any software project, especially
for the long term. A language as flexible as Perl facilitates good coding in every stage of the
software project. Although this book focuses on Perl, many of the principles are valid for other
languages such as C, C++, Java, and Python.

Finally, be an innovator. Regardless of your position in the team -- manager or member -- always
look for new ideas and put them into action. Perfection may be impossible, but it's a worthy goal.
Innovators are the true strength of a team and without them the melody grows stale very quickly.
Stay in touch with your peers; continually learn new things from them. A medium such as Usenet
(see
Resources)
is a great place for an exchange of ideas. Teach and learn, to and from each other. Remember,
there's always room for improvement. Above all, have fun, and let the music begin.

About the author
Teodor Zlatanov graduated with an M.S. in computer engineering from Boston University in 1999.
He has worked as a programmer since 1992, using Perl, Java, C, and C++. His interests are in open
source work on text parsing, 3-ti

FAIR USE NOTICE This site contains
copyrighted material the use of which has not always been specifically
authorized by the copyright owner. We are making such material available
in our efforts to advance understanding of environmental, political,
human rights, economic, democracy, scientific, and social justice
issues, etc. We believe this constitutes a 'fair use' of any such
copyrighted material as provided for in section 107 of the US Copyright
Law. In accordance with Title 17 U.S.C. Section 107, the material on
this site is distributed without profit exclusivly for research and educational purposes. If you wish to use
copyrighted material from this site for purposes of your own that go
beyond 'fair use', you must obtain permission from the copyright owner.

ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no
less then 90 days. Multiple types of probes increase this period.

The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be
tracked by Google please disable Javascript for this site. This site is perfectly usable without
Javascript.

Original materials copyright belong
to respective owners. Quotes are made for educational purposes only
in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains
copyrighted material the use of which has not always been specifically
authorized by the copyright owner. We are making such material available
to advance understanding of computer science, IT technology, economic, scientific, and social
issues. We believe this constitutes a 'fair use' of any such
copyrighted material as provided by section 107 of the US Copyright Law according to which
such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free)
site written by people for whom English is not a native language. Grammar and spelling errors should
be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development
of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or
referenced source) and are
not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with.We do not warrant the correctness
of the information provided or its fitness for any purpose.