var Turtle1 var Turtle2 var Is_Turtle

  • henfredemars@infosec.pub
    link
    fedilink
    English
    arrow-up
    5
    ·
    2 months ago

    Try assembly language! You have registers, and they are named for you with highly memorable names like R17.

  • parpol@programming.dev
    link
    fedilink
    arrow-up
    2
    ·
    edit-2
    2 months ago

    Yeah, a name should describe what it is or does, so if you have two turtles, and let’s say turtle1 wants to shit on turtle2’s lawn, you could name them shittingTurtle and victimTurtle. If the name alone tells you what its purpose is, that saves a lot of time for people looking at your code.

    Is_Turtle is not a bad variable name because it tells you it is a Boolean with “is” and that the Boolean tells you whether something is a turtle or not.

    Also, depending on the language, I suggest either camelCase or snake_case naming of variables. PascalCase is usually for defining classes or in case of C#, methods.

    • Repple (she/her)@lemmy.world
      link
      fedilink
      arrow-up
      3
      ·
      2 months ago

      SHOUTING_SNAKE_CASE aka SCREAMING_SNAKE_CASE is the best case for all use cases, because it gives you a chance to use its wonderful names.

    • MajorHavoc@programming.dev
      link
      fedilink
      arrow-up
      1
      ·
      2 months ago

      Thank you for this. This is awesome.

      shittingTurtle and victimTurtle are going into one of my professional slide decks as soon as I think I can get away with it.

  • Kojichan@lemmy.world
    link
    fedilink
    arrow-up
    2
    ·
    2 months ago

    I remember an old mentor programmer I had who basically described his job as building an addition to an addition to an addition on a tree house built in a twig.

      • _stranger_@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        2 months ago

        Have you considered multiple inheritance. It’s an upgrade. All upside, literally no downside. I’m trustworthy. Trust me.

      • Dr. Wesker@lemmy.sdf.org
        link
        fedilink
        English
        arrow-up
        0
        ·
        edit-2
        2 months ago

        When you start learning about different paradigms, you’ll likely learn much more about inheritance when learning about the Object Oriented design paradigm.

        To overly simplify, you create objects that inherit attributes from other objects. It’s for instance a way to create reusable patterns, that have stronger and more reliable data structures.

        I made the joke comment, because for instance, you could create a Turtle class, and always know it was a Turtle. Again, an oversimplification.

        EDIT: I should also add that for some reason OOP is an oddly divisive subject. Developers always seem to want to argue about it.

          • Dr. Wesker@lemmy.sdf.org
            link
            fedilink
            English
            arrow-up
            1
            ·
            edit-2
            2 months ago

            If I could give a suggestion I wish I had gotten much earlier on in my education and career, it would be to really spend some time learning about the different paradigms, and their best use cases. You will likely ensure yourself a strong foundation in software architecture.

          • arendjr@programming.dev
            link
            fedilink
            arrow-up
            0
            ·
            2 months ago

            Just keep in mind that inheritance is nowadays a very contested feature. Even most people still invested in object oriented programming recognise that in hindsight inheritance was mostly a mistake. The industry as a whole is also making a shift to move more towards functional programming, in which object orientation as a whole is taking more of a backseat and inheritance specifically is not even supported anymore. So yeah, take the chance to learn, but be cautious before going into any one direction too deeply.