Hacker Newsnew | comments | show | ask | jobs | submitlogin

  void up_front_decls()
  {
    float some_var;
    int another_var;
    
    some_var = get_some_var();
    do_some_calculations(some_var);
    maybe_something_else(&some_var);
    
    some_var = get_another_var();
    do_some_other_calculations(another_var);
    blah_blah_already_broken();
  }

  void as_needed_decls()
  {
    float some_var = get_some_var();
    do_some_calculations(some_var);
    maybe_something_else(&some_var);
    
    int some_var = get_another_var();
    // compile-time error
    // ...
  }

Also:

  void poor_style()
  {
    up_front            declarations;
    also                encourage;
    this_ridiculous    *block_style;
    that_is             a_royal_pain;
    to                  maintain;
    because_some_long_type inevitably;
    screws_it           up;
  }



Finally got the silly regex. To align poor_style in vim with the tabularize plugin:

:Tab /\S\s\zs[ ]\S*

Explanation: \S\s* finds a non whitespace character followed by as many whitespace characters as possible. This brings us to the beginning of the variable name. We then use \zs which says that the "found" area should only begin here.

Since we want the * in block_style to be attached to the indented word but not before the variable name, we match either * or space followed by a non-whitespace character to symbolize the beginning of the word. End result:

  void poor_style()
  {
    up_front                declarations;
    also                    encourage;
    this_ridiculous        *block_style;
    that_is                 a_royal_pain;
    to                      maintain;
    because_some_long_type  inevitably;
    screws_it               up;
  }

-----


I would argue that if declaring up-front versus declaring as-needed makes a significant difference in readability, then your functions are too long.

-----


Except for loop counters. Being able to do:

  for (int i = 0; i < len; ++i) { ... }
vs.

  int i;
  // Half a dozen lines
  for (i = 0; i < len; ++i) { ... }
makes a big difference to me.

-----


Regarding poor_style(), I've never understood this objection (and indeed I prefer the block style you complain about there). Can't your editor fix this up for you in a few keystrokes? This is the sort of thing that an editor should make easy.

-----


I have a few objections:

1. It wastes my time. Sure, I could probably set up my editor to fix this, but I shouldn't have to do so to satisfy someone else's pointless indentation fetish. I've personally never worked on a team where this was an accepted, general guideline. It was always just one guy who wanted this, and did it to every function he touched, adding maintenance headaches for everyone else (until/unless other people finally told him to stop).

2. It messes up diffs. Now instead of one line showing up in the diff, the entire block is often different. And yes, most diff tools have options to hide whitespace differences. Again, though, this adds overhead to everyone who doesn't want this block style. I'd rather not hide whitespace differences, because if someone has added a bunch of inappropriate whitespace (or mangled the block while trying to reformat it to include their new variable), I want to know about it during the code review so I can tell them to fix it then rather than finding it later when I'm editing the file.

3. It doesn't actually help anything. Yes, you get a nice column that shows you all the variable names. What good is that, though? Unless you're putting everything at the top of the function (which has its own set of problems), you're not really getting anything useful from this except maybe prettier code (arguable), because at a glance you still don't really get know all the in-scope variables (not to mention file-scope variables). Moreover, you actually lose something valuable with this style, because now it's harder to determine a variable's type. You're trying to scan left from the name across some indeterminate amount of whitespace to match with the type. This is not typically easy to do, which is why column-oriented data is typically displayed with alternating background colors on each row.

-----


I bet that some programmers' brains need those orderly columns in order to be able to parse the code effectively, overwhelmed by the chaos of rivers of whitespace otherwise. In that case, it sounds like an editor that displays in columns but stores in compact form would be helpful.

-----


That's certainly possible, and I agree with your idea that those devs should use the custom editor setup they need instead of expecting everyone else to accommodate them.

-----


Your up fornt example isn't a result of poor style it's the result of a bad programmer. Assigning the right values to the right variables is the most basic of programming concepts. Sure typo's and bugs happen, I've done it too but it's still a programmer error not style error.

-----


Any style that encourages errors is a bad style. Yes, it's possible to make the code correct and still use up-front declarations. It's also possible to make the code correct while using a 10k-line main() littered with gotos. It's still a very poor programming style.

People make mistakes. Practices should be built around this fact, not built assuming people could be perfect if they just tried a little harder.

-----


Have you ever seen a bug caused by this? I haven't. At least anecdotally, this is purely stylistic, and has no impact outside of personal preference.

With one caveat: Heavy constructor/destructor use requires it.

-----


Yes. I have absolutely seen bugs caused by the wrong variables being assigned to. I've seen it especially with loop variables. jaegerpicker indicates that he's also caused bugs by assigning to the wrong variables.

Not sure what you mean about "heavy constructor/destructor use" requiring this style.

-----




Guidelines | FAQ | Support | API | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: