Naming conventions



  • We don't have a real naming convention in our shop. Sometimes we use p_ for parameters, mostly we don't; sometimes we use type prefixes, mostly we don't - it's not too confusing because the names actually make sense most of the time. Except when they don't.

        bool isBool = false;
    
        string strStr = "<sql query>";
    
        int num = Convert.ToInt32(fieldName.Substring(7, 1));
    

    My favourite is the constructor parameter which is only used to choose an overload:

      public C() {
          ...
      }
    
      public C(bool p_isBool) : this() {
          ... a lot more code that doesn't use p_isBool ...
      }
    


  • Just to be clear: those are not problems of a lack of a formal naming convention.

    It's a problem of short-sighted programmers.



  • I definitely agree. I just called it "naming conventions" because the variable names look like they're entirely convention and they forgot the actual name part.



  • @configurator said:

    I definitely agree. I just called it "naming conventions" because the variable names look like they're entirely convention and they forgot the actual name part.
    My experience is that you cannot fix stupid with conventions.


  • BINNED

    @configurator said:

    bool isBool = false;
    That reads like a paradoxon right there.

     

    @configurator said:

    My favourite is the constructor parameter which is only used to choose an overload:
    That's not totally unheard of, though. C.f.

    operator new(nothrow_t)


  • @topspin said:

    That's not totally unheard of, though. C.f.

    operator new(nothrow_t)

    Well at least there the eventual syntax makes (some) sense - you call new(nothrow) X instead of new X. Here, the syntax is C(false) instead of C() which doesn't tell you anything about what it means (and even after reading the code inside the constructor, I have absolutely no idea what it means - luckily I haven't had to construct an instance of this object). Even a singleton enum would be better:

      public enum DoSomethingDifferently { Yes };
      public C() { ... }
      public C(DoSomethingDifferently p) : this() { ... }
    

    Although I would prefer

      public enum DoSomething { Normally, Differently };
      public C(DoSomething how = DoSomething.Normally) { switch (how) { ... } }
    

    Which gives you the same optional parameter except the value you send in actually tells you what to do rather than which overload to use.



  • @Rick said:

    My experience is that you cannot fix stupid with conventions.

    A fav quote I heard a long time ago:

    Ignorance can be cured with education

    Stupidity can only be cured with a hand gun.


  • @OzPeter said:

    Stupidity can only be cured with a hand gun.
     




  • @configurator said:

        bool isBool = false;

    So, it's not a bool?


  • Considered Harmful

    @CarnivorousHippie said:

    So, it's not a bool?

    You're reading it backward. False isBool. Bool.



  • @Cassidy said:

    @OzPeter said:

    Stupidity can only be cured with a hand gun.
     


    Hey, cool gun! I love the re-imagined UI. Having the front sight closer to my face like that makes it so much more discoverable - usability win! Mind if I try it out?



  • @Cassidy said:

    @OzPeter said:

    Stupidity can only be cured with a hand gun.
     


     

    Winnar!

     



  • @dhromed said:

    It's a problem of short-sighted programmers.
    So? There are a couple of easy fixes for that. Give them bigger monitors, or if the company can't afford that, tell them to sit closer to them. Or to get some f-ing glasses (or contacts if they're too vain). Problem solved.



  •  You're talking about near-sighted programmers.



  • @flabdablet said:

    Mind if I try it out?
     

    Shoot, go ahead.


  • FoxDev

    @configurator said:

    sometimes we use type prefixes, mostly we don't
     

    I never use type prefixes - if the type isn't obvious from the name, think of a new name.

    Don't think I'm against Hungarian notation though; cOrders is a perfectly valid use.

     



  • @Cassidy said:

    Shoot, go ahead.

    Hey, thanks! This thing is so cool. So many affordances! Look, there's a cute little curvy bit that just fits my fing



  • That went with a bang, then.

     



  • @RaceProUK said:

    I never use type prefixes - if the type isn't obvious from the name, think of a new name.

    Same here. If you don't know that name is a string, you've got bigger problems.

    Then again, we have many tables with columns called "*ID", "*Code" and "*Name", of types int, string and string-that-always-contains-a-small-number. Sometimes even references to columns with different types but the same values. So maybe we do need the type sometimes... But in those cases we never actually have prefixes - we only ever use them where it's already obvious.


  • Considered Harmful

    @RaceProUK said:

    I never use type prefixes - if the type isn't obvious from the name, think of a new name.

    We don't use prefixes except for ASP.NET controls. I think it's because it's common to have groupings of related controls like a lblFirstName and a txtFirstName and maybe a req[uired]FirstName.


Log in to reply