On Tue 14 Dec 2004 17:10, Adam Turoff <[EMAIL PROTECTED]> wrote:
> On Tue, 14 Dec 2004 16:14:32 +0100, H.Merijn Brand <[EMAIL PROTECTED]>
> wrote:
> > On Tue 14 Dec 2004 16:04, "Clayton, Nik" <[EMAIL PROTECTED]>
> > wrote:
> > > I've normally got enough going on in my head when writing code,
> > > worrying about the house style should not be one of them.
> >
> > Wrong. It should be. You write, and someone else - or yourself - has
> > to maintain the code later. This means that you have to write with
> > style and maintainability in focus. All the time.
>
> Part of the problem is that "coding style" mixes a bunch of unrelated
> issues of varying importance. I'm with Nik that I don't care overmuch
> about how many spaces go around parens, whether curlys are cuddled or
> uncuddled, or tab expansion idiosyncracies.
>
> But there *are* issues of coding style that are of tremendous import,
> and can add or reduce friction on a project, especially as it grows.
> Things like line length, method length, naming conventions, file layout,
> idiomatic usage[*], etc.
>
> One example I've used in the past is from a project I worked on (in C)
> where we were dealing with "real estate data numbers", commonly
> abbreviated 'rednum'. Except that they were also named, 'red', 'redno',
> 'rnum', 'red_num', 'red_no', 'r_num', and so on. In both variables and
Ohhh, the horror. And so recognizable!
> functions. This was one of many sources of dissonance (and compiler
> errors) on the project, and was a continual drag on team productivity.
> Instead of just *knowing* what you needed, you often needed to grovel
> through half a dozen source files to figure out what you *should* have
> typed.
This was underlighted in my example, but indeed evenly important.
We've chosen to make default prefixes to veriables to reflect the
(database) type:
d_end All dates start with d_ (we use plain numeric 8
YYYYMMDD because none of the databases we work
with have compatible date formats
(fwiw we also have d_end_y, d_end_m, and d_end_d, which I now
presume does not need any further explanation :))
c_city (key) code of a field that has a reference table
s_city The string value for c_city
and so on.
> But we all used the same brace placement and indenting styles. ;-)
About spaces, another thing springs to mind, for which I would gladly kill the
responsible people to allow it (I bet M$ was the first to push it): Spaces in
database table and field names. DON'T! NEVER! Once you start it, you will
never be able to escape the quicksands of (incompatible) quotation and
unportability of your scripts, be that in sql, sh, perl/dbi, hli, or e/sql
If you want to have portability in mind, adhere to the lowest level of
available standards and don't be tempted to use archaic functions specific to
a unique version of a database on a unique version of an operating system wich
only runs on a specific architecture.
> > FWIW the style I use was decided upon back in the 80's when we (me and
> > 6 others) had to do a huge software project at school and we did
> > discuss style before we started. The biggest argue was about the
> > length of the variable names to use.
>
> This is where I think Uncle Bob is right -- the standards need to
> evolve. On this same project, there was a coding standard in place at
> the onset, but it standardized trivialities. Because we had a coding
> standard, we never saw the bigger issues of naming conventions as
> problems a coding standard could/should fix, so everyone improvised in
> their own special way with the stuff that wasn't standardized. At the
> onset, though, a lot of issues we had to deal with were completely
> unknown, since the project took three or four major course changes over
> the years.
If all of this is true, I think we made marvellous decisions in our school
days, because none of my coding standards have changed, but the decrease of
an indent of 6 (very nice when programming PASCAL) to an indent of 4 (better
suited for almost any other language, and since TAB is 8, much more efficient).
> Z.
>
> *: For example: design with closures and coderefs in mind, or with big
> modules with 17 optional features or 15 variations on the same
> method; are you intetionally using or avoiding map and grep?; what
> are the standard modules your project uses to write new classes?
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.5, & 5.9.x, and 809 on HP-UX 10.20 & 11.00, 11i,
AIX 4.3, AIX 5.2, SuSE 9.1, and Win2k. http://www.cmve.net/~merijn/
http:[EMAIL PROTECTED]/ [EMAIL PROTECTED]
send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
