A collection of Bad Code Smells in a Catalog form for Developers & Researchers. Code Smell is a typical bad code implementation, and learning these concepts immiedietly makes you a better developer!
  • Boomkop3@reddthat.com
    0·
    2 days ago

    There are arguments to be made either way, but normally you’d scope your variables in a way that the ones specific to a particular bit of code are not accessible from elsewhere.

    They’re arguing to do this:

    int field = 1;
void may() {
   do(field);
}

int field = 3;
void you() {
   do(field);
}

int field = 3;
void be() {
   do(field);
}

int field = 7;
void happy() {
   do(field);
}

    rather than

    int field = 1;
int field = 3;
int field = 3;
int field = 7;

void may() {
   do(field);
}
void you() {
   do(field);
}
void be() {
   do(field);
}
void happy() {
   do(field);
}

    A bad example of encapsulation would be:

    class AClass {
    private class HelloThere {
         int a = 1;
         int b = 3;
         int c = 3;
         int d = 7;
         void DoStuff(AClass self) {
              Do(a, b);
         }
    }
    private HelloThere field = new();
    void World() {
        field.DoStuff(this);
    }
}

    Of course, there is nuance here. Is this class encapsulating enough that it’s got a right to exist? That’ll depend on the situation.

    Also, c has local static variables. Depending on your use case, it might just be easier in c than in C# and similar.

    // a method with a state, horrid in some contexts, great in others
void PrintCounter() {
    static int count = 0;
    Print(count);
    count += 1;
}

    And just in case you’re still reading and curious:

    #region PingPong
    // hi! I am in a region, collapse me using your ide!
#endregion
      • Boomkop3@reddthat.com
        0·
        1 day ago

        In most cases it’s a bad idea, yes.

        Also, have another look at that example code snippet though: that static variable is local to that function. It’s a weird feature in c.

        I’ve used it quite often in embedded code where a single variable was only for one function, and only for that one app/device. Wrapping it in a struct would’ve made the code needlessly more complex (that’s a code smell). And yet, these static locals are very easy to refactor to one local to a struct. May the situation change, that’s still an option.

        • FizzyOrange@programming.dev
          0·
          1 day ago

          that static variable is local to that function

          Yes I know how static storage durations work. It’s still global state, which is a code smell. Actually I’d go as far as to say global state is just bad practice, not just a smell. Occasionally it’s the only option, and it’s definitely the lazy option which I won’t claim to never take!