Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

Re^2: Seeking Best Practices - does your company follow a standard?

by Herkum (Parson)
on May 05, 2010 at 21:19 UTC ( #838577=note: print w/ replies, xml ) Need Help??


in reply to Re: Seeking Best Practices - does your company follow a standard?
in thread Seeking Best Practices - does your company follow a standard?

While sometimes coding policies can be nit-picky they can sometimes be very useful. One place I worked at had no coding standards either. The result was code that no one understood or could support. It was fairly common to have 1 subroutine to be 2000 lines! I repeat 2000 lines! What the hell!

I am not saying coding standards are going to everything, but without them, the quality can very greatly depending on the skill level of the programmer...


Comment on Re^2: Seeking Best Practices - does your company follow a standard?
Re^3: Seeking Best Practices - does your company follow a standard?
by JavaFan (Canon) on May 05, 2010 at 22:07 UTC
    One place I worked at had no coding standards either. The result was code that no one understood or could support. It was fairly common to have 1 subroutine to be 2000 lines! I repeat 2000 lines! What the hell!
    Yes, and?

    Are you suggesting to solve that with a coding standard that says "No subroutine shall be more than N lines"? What should N be? 1000? 100? 10? 2? Does N include lines that contain nothing but comments? Nothing but white space? Nothing but an opening or closing parenthesis? What if the result of picking an N is that programmers start using nested maps on a single line, instead of multiline nested for loops, just so their subroutines fit in the N line maximum?

    I can imagine cases where a single 2000 line subroutine is preferable over splitting it up. There are 10 line subroutines that should be split up in two separate routines.

      Piffle.

      That you have to imagine cases where 2000 line subs are preferred, tells me exactly how often such cases really occur: almost never.

      In 10 years of coding Perl for a living, I have never seen a 2K LOC subroutine that wasn't 90% scaffolding that should have been abstracted away into other modules, with the remaining 200 lines doing 5 to 10 different things that should have been tucked into their own, nicely named subroutine.

      Programmers will use their first working solution as a template for every similar project, you can bet the codebase is a massive pile of cut and paste, long past being maintainable.

      The issue isn't one one of arbitrarily counting elements of syntax, but clarity of expression: at every level, any reasonably experienced reviewer should be able to see what the code is doing and how it fits into the big picture, without having to think about it.

      2000 line subroutines require exponentially more time to understand and review than a group of small subroutines, because they require exponentially more time than the 10 to 20 smaller (by 2 orders of magnitude) subs a decent implementation would probably use.

      If 2000 line subs are common where the man works, something his company's programming culture is badly messed up, and nothing short of wholesale replacement of the entire development staff from the top down will make things better.

      He should get out before that culture infects him to any great extent.

        That you have to imagine cases where 2000 line subs are preferred, tells me exactly how often such cases really occur: almost never.
        Right. And that's the point, ain't it. "Almost never" isn't the same as "never". And that doesn't answer my question. How are you going to codify that in a coding standard? We have established that you think 2000 is too much. How about 1999? How about 1998? ... How about 5? How about 4? How about 3? Where do you draw the line? And how do you justify that exactly the limit is ok, but one line more isn't?
        In 10 years of coding Perl for a living, I have never seen a 2K LOC subroutine that wasn't 90% scaffolding that should have been abstracted away into other modules, with the remaining 200 lines doing 5 to 10 different things that should have been tucked into their own, nicely named subroutine.
        I don't have that awesome memory. In fact, I can't even remember of the subroutines I saw earlier this week how much "scaffolding" there was - let alone remembering them over a 10 year line span.

        Programmers will use their first working solution as a template for every similar project, you can bet the codebase is a massive pile of cut and paste, long past being maintainable.
        Hmmm, I'm not going to question your observation (which doesn't match mine), but what had this to do with the subject?
        2000 line subroutines require exponentially more time to understand and review than a group of small subroutines, because they require exponentially more time than the 10 to 20 smaller (by 2 orders of magnitude) subs a decent implementation would probably use.
        Really? Always? Does 2000 lines of code somehow suddenly always become easier to understand if we scatter the lines into different subs, possible split over different files? Note that I'm not denying that this is often the case - my claim is that sometimes it isn't. If to understand the entire working of a sub means understanding all the pieces, and their order, moving those pieces away doesn't make it easier to understand. In fact, it becomes more annoying - as the linear flow is gone (it's like reading a text where you got to have read the footnotes at the end of the chapter to understand it). And argument passing actually means more code, which sometimes can make it harder.
        If 2000 line subs are common where the man works
        Beep! Red Herring Alert! Stating that SOMETIMES a thing may happen in no way means such a thing is common.
        He should get out before that culture infects him to any great extent.
        While we are in the subject of making broad generalizations, I think anyone claiming "never" or "always" isn't fit as a programmer, and should never (;-))have been hired. You claim 2000 line subroutines are always bad - just based on line count? Step away from the keyboard and never touch it again.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://838577]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (6)
As of 2014-09-19 03:57 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (129 votes), past polls