Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

comment on

( #3333=superdoc: print w/replies, xml ) Need Help??

Recently, I've had some discussions with grep regarding coding standards. Some of the standards have been fairly straight-forward. Code must use strict, run clean under warnings (unless special permission is sought under exceptional cases), encapsulated functions, etc. Those are pretty standard, but grep noticed that my coding style has changed a little bit and he asked me about it. Since I've been evaluating several different editors such as Homesite, Textpad, vim, etc, I have adopted an "editor-neutral" coding style. grep was considering making this a standard, but so many programmers consider this a near-religious issue that I am concerned that we won't see enough benefit compared to programmer gripes.

Here are the basic points of the style that I am using:

1. Indent data structures and arguments to subs rather than leaving them hanging off to the right:

sub ugly_formatting { my %conn_data = @_; my $dbh = DBI->connect( $conn_data{ data_source }, $conn_data{ use +r }, $conn_data{ pass }, { RaiseError => 1, AutoCommit => 0, LongReadLen => 65_634 } ) or die DBI->er +rstr; $dbh; }

Instead, I do this:

sub _connect { my %conn_data = @_; my $dbh = DBI->connect( $conn_data{ data_source }, $conn_data{ user }, $conn_data{ pass }, { RaiseError => 1, AutoCommit => 0, LongReadLen => 65_634 } ) or die DBI->errstr; $dbh; }

2. Curly braces should be aligned vertically over themselves on the same scope, rather than trailing off the end of a line. Quick, where's the missing brace:

if ( exists $database->{ $table }{ _unique } ) { my @unique_fields = @{ $database->{ $table }{ _unique } }; foreach my $field ( @unique_fields ) { my %field_count; my $sql = "SELECT $field FROM $table"; my $fields = $dbh->selectall_arrayref( $sql ); foreach ( @$fields ) $field_count{ $_->[0] }++; } foreach ( keys %field_count ) { if ( $field_count{$_} > 1 ) { print $err "Table: '$table' Unique field: '$_' was fou +nd $field_count{$_} times\n"; $error_count++; } } } # next $field }

If you vertically align corresponding braces:

if ( exists $database->{ $table }{ _unique } ) { my @unique_fields = @{ $database->{ $table }{ _unique } }; foreach my $field ( @unique_fields ) { my %field_count; my $sql = "SELECT $field FROM $table"; my $fields = $dbh->selectall_arrayref( $sql ); foreach ( @$fields ) $field_count{ $_->[0] }++; } foreach ( keys %field_count ) { if ( $field_count{$_} > 1 ) { print $err "Table: '$table' Unique field: '$_' was fou +nd $field_count{$_} times\n"; $error_count++; } } } # next $field }

To me, the problem just leaps out at me. As I sometimes wind up with really complex structures, vertical alignment of the braces seems to help.

3. Indentation can start with tabs for leading whitespace, but embedded whitespace must be spaces.

That might sound a bit weird, but many editors have tabs at different settings. Maybe they're 8 spaces. Maybe they are 4 or 2 (I've heard rumors of them viewing as 6 spaces, what heresy!). By ensuring that only leading whitespace (/^\s+/) is tabs (spaces are okay, too), but all embedded whitespace is comprised of spaces, you ensure that code won't wind up with a bizarre visual appearance, depending on the editor. For example, I recently encountered the following code (tabs are changed to spaces so you can see what I mean):

my %page_control = ( Add => { EmploymentListing => { page => 'e +m-main-add-employment.tmpl', function => \&add_emp +loyment } }, Edit => { EmploymentListing => { page => 'e +m-main-update-del-employment.tmpl', function => \&update +_delete_employment } }, Delete => { EmploymentListing => { page => 'e +m-main-update-del-employment.tmpl', function => \&update +_delete_employment }

Now, that's pretty ugly, but that's with tabs rending four spaces in width. I opened this up to work on it in an editor that renders tabs as being eight spaces wide:

my %page_control = ( Add => { EmploymentListing => { page => 'e +m-main-add-employment.tmpl', + function => \&add_employment } }, Edit => { EmploymentListing + => { page => 'em-main-update-del-employment.tmpl', + function => \&update_delete_employment } }, Delete => { EmploymentListing + => { page => 'em-main-update-del-employment.tmpl',

That's an even worse mess. I took some time to convert it:

my %page_control = ( Add => { EmploymentListing => { page => 'em-main-add-employment.tmpl', function => \&add_employment } }, Edit => { EmploymentListing => { page => 'em-main-update-del-employment.tmpl', function => \&update_delete_employment } }, Delete => { EmploymentListing => { page => 'em-main-update-del-employment.tmpl', function => \&update_delete_employment } } };

Note that rule 3 doesn't do that much good if rule 1 is ignored.

Now, here's the sad truth: I don't like this. Somehow, it grates against my sense of aesthetics. So why am I doing it? Because I think that in the long run, code is much cleaner and easier to read, regardless of the editor one chooses. Further, I feel that scoping issues will be easier to track down like this.

Here's the rub: is enshrining this into standards the way to go? I think many programmers would rebel. I really don't think we'll get much benefit. grep wants the standards, though, to ensure that we don't wind up with a bunch of different programmers reformatting everyone else's code every time they work on it (yes, I'm guilty of that :). Any thoughts?

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.


In reply to (OT) Editor-neutral code formatting by Ovid

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or or How to display code and escape characters are good places to start.
Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (1)
As of 2022-01-24 03:03 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    In 2022, my preferred method to securely store passwords is:












    Results (64 votes). Check out past polls.

    Notices?