• million@lemmy.world
    link
    fedilink
    English
    arrow-up
    6
    ·
    edit-2
    1 year ago

    Refactoring is something that should be constantly done in a code base, for every story. As soon as people get scared about changing things the codebase is on the road to being legacy.

    • NoXzema@lemmynsfw.com
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      Been with a lot of codebases that had no unit tests at all and everyone was afraid to change anything because the QA process could take weeks to months.

      The result is you have a codebase that ages like milk.

      • FlumPHP@programming.dev
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        Today I removed code from a codebase that was added in 2021 and never ever used. Sadly, some people are as content to litter in their repo as they are in the woods.

    • brettvitaz@programming.dev
      link
      fedilink
      arrow-up
      0
      arrow-down
      1
      ·
      edit-2
      1 year ago

      Only if the code base is well tested.

      Edit: always add tests when you change code that doesn’t have tests.

  • AdmiralShat@programming.dev
    link
    fedilink
    English
    arrow-up
    6
    arrow-down
    1
    ·
    edit-2
    1 year ago

    If you don’t add comments, even rudimentary ones, or you don’t use a naming convention that accurately describes the variables or the functions, you’re a bad programmer. It doesn’t matter if you know what it does now, just wait until you need to know what it does in 6 months and you have to stop what you’re doing an decipher it.

    • fkn@lemmy.world
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      Self documenting code is infinitely more valuable than comments because then code spreads with it’s use, whereas the comments stay behind.

      I got roasted at my company when I first joined because my naming conventions are a little extra. That lasted for about 2 months before people started to see the difference in legibility as the code started to change.

      One of the things I tell my juniors is, “this isn’t the 80s. There isn’t an 80 character line limit. The computer doesn’t benefit from your short variable names. I should be able to read most lines of code as a single non-compound sentence in English with only minor tweaks and the English sentence should be what is happening in most of those lines of code.”

  • argv_minus_one@beehaw.org
    link
    fedilink
    arrow-up
    4
    ·
    1 year ago

    Dynamic typing is insane. You have to keep track of the type of absolutely everything, in your head. It’s like the assembly of type systems, except it makes your program slower instead of faster.

    • Cratermaker@discuss.tchncs.de
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      Nothing like trying to make sense of code you come across and all the function parameters have unhelpful names, are not primitive types, and have no type information whatsoever. Then you get to crawl through the entire thing to make sense of it.

      • Carol2852@discuss.tchncs.de
        link
        fedilink
        arrow-up
        1
        ·
        5 months ago

        Sure try to replace the one or two people that hold the whole team together. I’ve seen it a couple times, a good team disintegrates right after one or two key people leave.

        Also, if you replace half the team, prepare for some major learning time whenever the next change is being made. Or after the next deployment. 🤷‍♂️

    • NBJack@reddthat.com
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      Python should not be used for production environments, or anything facing the user directly. You are only inviting pain and suffering.

  • CodeBlooded@programming.dev
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    Python, and dynamically typed languages in general, are known as being great for beginners. However, I feel that while they’re fun for beginners, they should only be used if you really know what you’re doing, as the code can get messy real fast without some guard rails in place (static typing being a big one).

    • Herrmens@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      1 year ago

      Disagree on this one, even though I can see where you are coming from. I first learnt programming in Java, and it gave me massive problems to understand the structure and typings. Obviously Java isn’t the most beautiful language anyways, but once I picked up python it started to click for me on how to solve problems, because I didn’t have to think about that many things. I could just go for it. Yes, my code was messy in the beginning, but I wasn’t working on any important projects. It was just for fun.

      So I think learning how to solve problems is as important as writing clean code. And python really helped me with that.

      • stevecrox@kbin.run
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        3 months ago

        I’d actually argue Python stops people learning how to solve problems.

        I love teaching juniors and have done so for 10 years but I’ve noticed in the last 4-5 years since Python became the popular choice at universities Graduates aren’t learning anything about Static Types, Memory Management, Object Oriented Programming, Data Encapsulation, Composition, Service Oriented Architecture, etc…

        I used to expect most graduates to have a mixed grounding in those concepts and would find excuses for them to work on a small UI projects. I would do this as it gets them used to solving a small problem and UI’s give instant feedback. As Python became dominate university teaching language the graduates aren’t spending their time learning Typescript, Angular, HTML, etc… but instead getting overwhelmed by the concept of types.

        Those concepts I want them to learn were created to help make solving problems easier and each has their strengths and weaknesses but most graduates are coming through only knowing how to lay out a small amount of procedural logic using Python and really struggling to move beyond that.

  • Vince@feddit.de
    link
    fedilink
    arrow-up
    2
    ·
    edit-2
    1 year ago

    Not sure if these are hot takes:

    • Difficult to test == poorly designed
    • Code review is overrated and often poorly executed, most things should be checked automatically (review should still be done though)
    • Which programming language doesn’t matter (within reason), while amount of programming languages matters a lot
  • r1veRRR@feddit.de
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    Compiler checked typing is strictly superior to dynamic typing. Any criticism of it is either ignorance, only applicable to older languages or a temporarily missing feature from the current languages.

    Using dynamic languages is understandable for a lot of language “external” reasons, just that I really feel like there’s no good argument for it.

  • asyncrosaurus@programming.dev
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    SPAs are mostly garbage, and the internet has been irreparably damaged by lazy devs chasing trends just to building simple sites with overly complicated fe frameworks.

    90% of the internet actually should just be rendered server side with a bit of js for interactivity. JQuery was fine at the time, Javascript is better now and Alpinejs is actually awesome. Nowadays, REST w/HTMX and HATEOAS is the most productive, painless and enjoyable web development can get. Minimal dependencies, tiny file sizes, fast and simple.

    Unless your web site needs to work offline (it probably doesn’t), or it has to manage client state for dozen/hundreds of data points (e.g. Google Maps), you don’t need a SPA. If your site only needs to track minimal state, just use a good SSR web framework (Rails, asp.net, Django, whatever).

    • nayminlwin@lemmy.ml
      link
      fedilink
      arrow-up
      0
      ·
      1 year ago

      I’m still hoping for browsers to become some kind of open standard application environments and web apps to become actual apps running on this environment.

      • icesentry@lemmy.ca
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        How are browser not that already? What’s missing?

        They are an open standard and used to make many thousands of apps.

  • hansl@lemmy.ml
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    Hot take: people who don’t like code reviews have never been part of a good code review culture.

  • chicken@lemmy.dbzer0.com
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    I am not smart enough to effectively code with certain languages and design patterns and that’s ok. There is nothing wrong with accessibility being prioritized or with making tradeoffs for the sake of reducing complexity.

  • BrotherL0v3@lemmy.world
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    Tools that use a GUI are just as good (if not better) than their CLI equivalents in most cases. There’s a certain kind of dev that just gets a superiority complex about using CLI stuff.

  • bidenicecream [none/use name]@hexbear.net
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    1 year ago

    Computer hardware has been getting faster and faster for decades at this point, but my computer still slows down. Like WTF. The dumbass programmers take the extra power given to them and squander it instead of optimizing their code. Microsoft word could run pretty well on a windows 98 PC, but the new Word can slow down PCs that are 5-10 years old. Programmers are complete idiots sometimes…

  • Elderos@lemmings.world
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    1 year ago

    The best codebase I have ever seen and collaborated on was also boring as fuck.

    • Small, immutable modules.
    • Every new features was coded by extension (the ‘o’ in S.O.L.I.D)
    • All dependencies were resolved by injection.
    • All the application life cycle was managed by configurable scopes.
    • There was absolutely no boiler plate except for the initial injectors.
    • All of the tests were brain-dead and took very minimal effort to write. Tests served both as documentation and specification for modules.
    • “Refactoring” was as simple as changing a constructor or a configuration file.
    • All the input/output of the modules were configurable streams.

    There is more to it, but basically, it was a very strict codebase, and it used a lot of opinionated libraries. Not an easy codebase to understand if you’re a newbie, but it was absolutely brain dead to maintain and extend on.

    Coding actually took very little time of our day, most of it consisted of researching the best tech or what to add next. I think the codebase was objectively strictly better than all other similar software I’ve seen and worked on. We joked A LOT when it came time to change something in the app pretending it would take weeks and many 8 pointers, then we’d casually make the change while joking about it.

    It might sound mythical and bullshity, and it wasn’t perfect, it should be said that dependency injection often come in the form of highly opinionated frameworks, but it really felt like what software development should be. It really felt like engineering, boring and predictable, every PO dreams.

    That being said, I given up trying to convince people that having life-cycle logic are over the place and fetching dependencies left and right always lead to chaos. Unfortunately I cannot really tell you guys what the software was about because I am not allowed to, but there was a lot of moving parts (hence why we decided to go with this approach). I will also reiterate that it was boring as fuck. If anything, my hot take would be that most programmers are subconsciously lying to themselves, and prefer to code whatever it is they like, instead of what the codebase need, and using whatever tool they like, instead of the tools the project and the team need. Programming like and engineer is not “fun”, programming like a cowboy and ignoring the tests is a whole lot of fun.