Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • by Damian (784) on 2006.02.22 18:59 (#46288)
    Is it really okay to deviate from PBP or [are] the guidelines really better?
    As I said in Chapter 1 of the book:
    As you consider these pieces of advice, think about each of them in the context of the type of coding you typically do. Question your current practice in the particular area being discussed, and compare it against the recommended approach. Evaluate the robustness, efficiency, and maintainability of your current coding habits and consider whether a change is justified.

    But remember that each of piece of advice is a guideline: a fellow programmer gladly telling you what his programming style is, and where he thinks other styles are unclear or make him jump through mental hoops. Whether or not you agree with all of them doesn’t matter. What matters is that you become aware of the coding issues these guidelines address, think through the arguments made in their favour, assess the benefits and costs of changing your current practices, and then consciously decide whether to adopt the solutions offered here.

    Be careful though. It's amazing how many arguments about coding practice are actually just rationalizations: carefully constructed excuses that ultimately boil down to either "It's not my present habit!" or "It's just too much effort to change!" Not changing your current practices can be a valid choice, but not for either of those reasons.

    Keep in mind that the goal of any coding style is to reduce your development costs by increasing the maintainability, robustness, and efficiency of your code. Be wary of any argument—either for or against change—that doesn’t directly address at least one of those issues.

    So, yes, it's okay to deviate from PBP, as long as you think through that deviation, weigh it against whatever criteria you're using to define good programming practice, and stay on guard against the all-too-human tendency to rationalize bad habits.
    • So, yes, it's okay to deviate from PBP, as long as you think through that deviation, weigh it against whatever criteria you're using to define good programming practice, and stay on guard against the all-too-human tendency to rationalize bad habits.

      It's been a really useful process. I'm self taught and work mostly in a team of one (me), so an external viewpoint is really useful. As I said in my original post, looking at every deviation has forced me to think, and while in most cases I've gone with the PBP

      --
      -- "It's not magic, it's work..."
      • I am in exactly the same boat. I have no programmers around me so I picked up Perl to do some things myself. PBP gives me a guideline to go by and I am always interested in other ways or opinions.
        • There is nothing wrong with being self taught, but you do need to obtain an external view point now and then to make sure your going the right way.

          I've been on a Red Hat and an IBM AIX training courses. On both couses I realised I knew a lot already (the Red Hat more so), which is useful confirmation, and I also picked up a better understanding and for AIX in particular I did pick up some new stuff.

          Reading the PBP book and using Perl::Critic is a good way of getting an external perspective, but it's onl

          --
          -- "It's not magic, it's work..."