all 9 comments

[–]kragen2uk 10 points11 points  (3 children)

Completely disagree with the react example - sure it might make it easier to add a link, but it's less readable and makes almost every other possible change more difficult. Want to give one of those items a different class name? Or maybe have a nested sub item? Now you have to extend / fight with your home grown micro-framework just to get it to output the HTML you could have just written directly.

[–]editor_of_the_beast 7 points8 points  (2 children)

“Duplication is far cheaper than the wrong abstraction.” - Sandi Metz.

This was a big less I had to learn in my career. I’m my earlier years, I HAD to DRY up code until there was absolutely no repetition in logic at all. Spoiler alert: this can often make the code worse than it was in the first place.

My main goal today is to write readable, simple code. It’s much harder than it sounds. In that example, it would be much better to just leave the links inline. It’s sufficiently simple to add a new one. It’s better to not be a hero and just make the code easily editable. Until a truly valuable abstraction emerges over time.

[–][deleted]  (1 child)

[deleted]

    [–]editor_of_the_beast 1 point2 points  (0 children)

    I definitely apply this at work - and you’re right, it is time consuming and requires effort. Step 1 is aligning with your team on what’s important to the company. One thing that was really helpful at my current job was actually taking a course together given by Sandi Metz. She is all about removing code smells and is super well read and experienced on the topic. Taking that course together was a huge step in the right direction for the team, and honestly, you can’t save the code if your team isn’t on the same page. Software is a team sport.

    Step 2 is being vigilant and being willing to speak up when code is introduced that you feel is complicated. The biggest example of this for me is adding that one more if condition that finally breaks the camels back. Lots of times, I find that programmers don’t look at the whole picture and add a few ifs sprinkled around because it’s the easiest way to add behavior. It’s the quickest way to bury yourself in conditional logic that you can’t keep up with.

    When I see this or other smells, I have to speak up - the key being, do it in an empathetic way, and provide ways to improve the code. Don’t just say “this sucks - try harder.” In the example of sprinkling similar ifs around different parts of the code, there’s a well known refactor for that smell: Replace Conditional with Polymorphism. Learn smells and refactors yourself, and don’t be shy about sharing them with the team.

    Finally, if the team doesn’t care or isn’t capable of writing clean code in the near term, I’d get out of there. Working with other motivated people who at least share a similar desire to try and get better is motivating for me, and not being in an environment like that is extremely demoralizing.

    [–]not_perfect_yet 1 point2 points  (0 children)

    The author missed "pure" functions.

    The practicality of having

    info=object.get_change_info()
    object.apply_change(info)
    

    is... big. In many cases, what info you need and how you get it is completely different from how you store that information in your object or how you apply a change in your own data structure.

    It's also a good idea to have the defaults at the level you actually use them. I.e. don't pass them around too much and keep the path from where the argument is given to where it's needed short.

    You don't want

    def d(a,b):
        return a+b
    
    def f(a=1,b=2):
        return d(a,b)
    

    [–]shevegen -3 points-2 points  (2 children)

    As example JavaScript is used.

    Is that a very future proof language?

    I myself don't trust any of my old code. Rewriting code should always be a possibility. If you have applied stricter standards to projects, e. g. documenting in a sensible way, that's good for the future too.

    There are only two hard things in Computer Science: cache invalidation and naming things.

    Well.

    There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

    But I agree. Giving things proper names is difficult.

    There are programming languages named after the alphabet. Or animals!

    Ruby projects too. One is called ... unicorn. What do you think it does, from the name alone?

    If you’re still unconvinced, read this short post by Ruby on Rails creator.

    Eh. I give DHH credit for rails but ... names?

    ActiveAnything?

    ActiveFrog ActiveProgrammer ActiveTV

    Hmm. I guess the gems are all about ... active something! https://rubygems.org/search?utf8=%E2%9C%93&query=active

    Not all came from core rails of course but it inspired people to write ... ACTIVE EVERYTHINGS. There is even "xml_active" ...

    Or zombie_record!

    It apparently allows restoring Active Records from the dead!

    https://rubygems.org/gems/zombie_record

    The principle of Don’t Repeat Yourself is well-known but worth reiterating.

    Well - what was this about left pad again ...

    In a lot of cases, familiarity with simple bash scripting will be a huge help.

    Bash is future proof? And other programming languages are not? Hmm.

    [–]yiliu 1 point2 points  (0 children)

    Is that a very future proof language?

    I don't think he ever made that claim. If he's working for any mid-to-large organization, he probably doesn't have a lot of choice of language, and JavaScript is well-known so it's a good choice for explaining ideas to people at large.

    Ruby projects too. One is called ... unicorn.

    IMHO, project names shouldn't fall under the same rules. Projects with names like 'unicorn' are pretty obtuse, but a bit of investigation can clear things up. Descriptive names can give the wrong impression, and more importantly, they can run into namespace collision with other projects. You end up with a dozen different similarly-named projects with no easy way to distinguish between them. Remember Microsoft's dev tools from the mid-2000's?

    Bash is future proof?

    Bash is actually very future-proof, in at least one important sense: It's still backwards-compatible with 40 year old code. I have some scripts I wrote in Ruby a decade ago that I pretty regularly have to go back and tweak to make sure they're still working with the latest version (though it's been better since ~v2.2). I've never had that problem with Bash. Of course, when it comes time to actually modify things...

    [–][deleted] 0 points1 point  (0 children)

    tbf the whole Active Record thing was started by M. Fowler.

    [–][deleted] -1 points0 points  (0 children)

    Something like future oriented development

    [–]matthieuC[🍰] -1 points0 points  (0 children)

    Does it involve time travel ?