Those who know, know.

  • rockkicker@kbin.run
    link
    fedilink
    arrow-up
    0
    ·
    4 months ago

    i guess this time the book involves a foreword in every chapter written by a woman that explains why they shouldn’t be allowed behind a computer

      • Eager Eagle@lemmy.world
        link
        fedilink
        English
        arrow-up
        0
        ·
        edit-2
        4 months ago

        twitter happened, I guess

        But today I stumbled across a long twitter thread that I can only describe as intentional character assassination. The author of this thread is misrepresenting facts and making some pretty nasty accusations. Again this is not all that unusual, except for the fact that I was not invited to defend myself. […] The gist of this author’s thread is that I am a misogynist; and that I should not be taken seriously in any regard. I understand that efforts have been made to have me excluded from conferences, and to boycott the publisher of my books, etc.

        - Uncle Bob in 2017

        source and context

        • Fonzie!@ttrpg.network
          link
          fedilink
          arrow-up
          0
          ·
          4 months ago

          So… What is the problem of women in tech? Either I skimmed over this or he fails to get to that point at all.

          • Eager Eagle@lemmy.world
            link
            fedilink
            English
            arrow-up
            0
            ·
            4 months ago

            well, that’s up to women in tech to explain what the movement advocates for, he’s laying out his experience

            • Fonzie!@ttrpg.network
              link
              fedilink
              arrow-up
              0
              ·
              3 months ago

              Not even that, he’s basically using 1000 word essay to say “I can’t be a misogynist, I hired women” as if that says anything. The words “the problem with women in tech” are both mentioned many times in the article as well as its title, but somehow it’s not about that problem at all, but the fact he got called a misogynist and that he now has conflicted feelings about it.

              Man, this is such a bad defence, let alone article.

        • SkyeStarfall@lemmy.blahaj.zone
          link
          fedilink
          arrow-up
          0
          ·
          edit-2
          4 months ago

          This is just a lot about people’s reactions to something, but nothing about what that something actually was

          It’d be nice to see what the actual something was so one could judge for themselves

          Edit: I took a look at his twitter, and he seems to be pro-trump and anti-kamala and anti-waltz, as well as transphobia thrown in here and there and more that I didn’t bother to read

          …so I’m gonna go with “the people’s reactions to him likely had a point”

          • Eager Eagle@lemmy.world
            link
            fedilink
            English
            arrow-up
            0
            ·
            edit-2
            4 months ago

            exactly, vague accusations in a lot of places, nothing remotely concrete.

            …so I’m gonna go with “the people’s reactions to him likely had a point”

            …and this is exactly the problem

              • LarmyOfLone@lemm.ee
                link
                fedilink
                arrow-up
                0
                ·
                edit-2
                4 months ago

                Hmm. The initial drama seems bullshit, starting a huge fight over the word “craftsmanship” is just hypersensitive at best or toxic behavior to manufacture outrage at worst. A gender neutral terms would be preferable but hardly the biggest issue right now.

                But since “uncle bob” supports Trump then that alone is enough to condemn him as a supporter of fascism and bigotry.

        • solrize@lemmy.world
          link
          fedilink
          arrow-up
          0
          ·
          4 months ago

          Interesting, thanks, I didn’t know anything about that. I’ve probably looked at the book at some point, but don’t remember anything about it.

      • Mossy Feathers (They/Them)@pawb.social
        link
        fedilink
        arrow-up
        0
        ·
        4 months ago

        I don’t have any examples personally, but I’ve been told by a lot of people that he has some views about women, race, sex, homosexuality, etc which many would find objectionable.

          • Mossy Feathers (They/Them)@pawb.social
            link
            fedilink
            arrow-up
            0
            ·
            edit-2
            4 months ago

            sigh I looked at his Twitter and it’s pretty standard right-wing politics. Maybe slightly more progressive than modern right-wingers, but still vomiting GOP propaganda.

            • Eager Eagle@lemmy.world
              link
              fedilink
              English
              arrow-up
              0
              ·
              4 months ago

              ok, I’m left, but how’s that of any relevance.

              if you can’t put a name or even quote an allegation, maybe you shouldn’t comment.

              there are lots of intellectually dishonest people intentionally misrepresenting what others say in the hopes others - like yourself - parrot it just for likes and visibility.

              • curbstickle@lemmy.dbzer0.com
                link
                fedilink
                arrow-up
                0
                ·
                4 months ago

                It’s not exactly news, his invitation to a conference was pulled because every other speaker refused to share a stage with him over his behavior / the politics he spews on Twitter.

  • quicken@aussie.zone
    link
    fedilink
    arrow-up
    0
    ·
    4 months ago

    I was a big Uncle Bob fan and still really like the Clean Code book. But he trashed his public reputation so I doubt this 2nd edition will do very well.

    • Max Günther@lemmy.today
      link
      fedilink
      Deutsch
      arrow-up
      0
      ·
      4 months ago

      I am also a big fan of his books, especially Clean Code. His (far-)right opinions are bad, but should be (to some extent) viewed separately from his technical standpoints. However, even then a new edition would not perform well, there are too many people hating Clean Code (without really understanding its message/just ranting without having read it). But I was very surprised that ThePrimeagen recently interviewed his “opponent”, it was very nice to watch.

  • arxdat@lemmy.ml
    link
    fedilink
    arrow-up
    0
    ·
    4 months ago

    There are no inherent “rules” in software development. These books are useless and a waste of time. They offer nothing but CS Dogma and are actually against freedom of expression.

    • orcrist@lemm.ee
      link
      fedilink
      arrow-up
      0
      ·
      4 months ago

      CS often requires working in teams, and working it teams is often more efficient if you have some shared approaches.

    • sus@programming.dev
      link
      fedilink
      arrow-up
      0
      ·
      edit-2
      4 months ago

      Rules of thumb can be very useful for a relatively inexperienced programmer, and once you understand why they exist you can choose to ignore them when they would get in the way. Clean Code is totally unhinged though

      • doktormerlin@feddit.org
        link
        fedilink
        Deutsch
        arrow-up
        0
        ·
        4 months ago

        The problem is that a lot of people don’t understand when to ignore the rules and just stick with them forever.

        We had a developer once that always said KISS KISS KISS whenever we pointed out that her functions are working but not reusable, so she wrote 20 functions that all did the same thing, but with slightly different parameters. And that’s just one of the examples

    • bleistift2@sopuli.xyz
      link
      fedilink
      English
      arrow-up
      0
      ·
      4 months ago

      There are no inherent “rules” to language, either, but when you don’t followthemthingsgetmessyandyou’reannoyingforeveryoneelese.

  • NigelFrobisher@aussie.zone
    link
    fedilink
    arrow-up
    0
    ·
    4 months ago

    New edition is just an incoherent rant about the “woke mind virus” trying to destroy him for “just saying what everyone is thinking”.

  • livingcoder@programming.dev
    link
    fedilink
    arrow-up
    0
    ·
    4 months ago

    The bit of Clean Code that I read was unimpressive, but Clean Architecture was amazing. I view that book as required reading for anyone who wants to write code professionally. If Uncle Bob hasn’t realized that his coding style is worse than alternatives, I do not see how a second version of the same bad ideas is going to do well.

  • Codex@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    4 months ago

    I should get to work on my opus, “Dirty Code”

    Inside I’ll reveal all my secrets like: not writing tests, not documenting anything, putting the whole app into a single python file, object-disoriented relational mapping, obscure SQL tricks, unobscure no-sql tricks, and more!

    • Eager Eagle@lemmy.world
      link
      fedilink
      English
      arrow-up
      0
      ·
      4 months ago

      object-disoriented

      I’ll steal this to shit talk about code; until git blame points to my past self

    • pfm@scribe.disroot.org
      link
      fedilink
      arrow-up
      0
      ·
      4 months ago

      I hope your book won’t have a table of context and those stupid indexes. If they read it, they should know where you mention topics, right? Tables of contents considered harmful! /s

    • tetris11@lemmy.ml
      link
      fedilink
      arrow-up
      0
      ·
      4 months ago

      Just make sure the first chapter is dedicated to spaghetti, and contains various GOTO statements telling where the reader where to go shove it and other obscenities.

    • Caveman@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      edit-2
      4 months ago

      He wrote for example the books Clean Code and Clean Architecture which are IMO opinion really good books although I don’t agree with every point he makes.

      Some really good points he makes are for example:

      • Functions that only do one job
      • Testing makes refactoring easier
      • The standard SOLID OOP stuff.
      • Tech debt is bad
      • Abstraction and encapsulation is good and allows developers to interact with the code on a higher level in terms of actions instead of writing verbose stuff. Essentially saying less code leads to less bugs
      • Insulate yourself from change
      • Duplication is bad
      • Two use cases that are very similar is not duplication and should not be refactored.
      • Don’t mix high level code with low level.
      • Build solid Entity classes to model the data and their interactions.

      Those comes with examples. He’s a tad bit overly idealistic in my opinion. These books fail to mention a couple of things:

      • Refactoring is expensive and the cost is often not justified.
      • Premature abstraction is the absolute devil
      • You don’t need to insulate from things that are very unlikely to change (like going from SQL to Document DB)
      • Less changes also lead to less bugs.
      • Too much emphasis on functions being few lines of code instead of just being simple.

      All in all though, very solid books. I read Clean Code in university and Clean Architecture in my first job and it really helped me wrap my head around different ways to solve the same problem. Excellent ideas but it’s not the holy truth. New programmers should read it and take inspiration, craftsman level developers should criticise it and expects can mostly skip it.

      • Waldowal@lemmy.world
        link
        fedilink
        arrow-up
        0
        ·
        4 months ago

        The consultancy I used to work for in the late 90s would have crucified any developer that didn’t write “a data abstraction layer that allows you to pop off the original db and substitute a different one later”.

        How many times in my 25 year career have I swapped out the database (and been thankful for such an abstraction layer)? 0 times.

        • evatronic@lemm.ee
          link
          fedilink
          English
          arrow-up
          0
          ·
          4 months ago

          I am literally in the middle of swapping DynamoDB for a RDBMS.

          The idea that you can abstract away such fundamentally different data stores is silly. While I hate doing it now, reworking the code to use relational models properly makes for a better product later.

          • Tja@programming.dev
            link
            fedilink
            arrow-up
            0
            ·
            4 months ago

            It’s literally what an orm does, and it’s good enough for 80% of apps out there. Using it for the wrong purpose is what’s silly.

            • evatronic@lemm.ee
              link
              fedilink
              English
              arrow-up
              0
              ·
              edit-2
              4 months ago

              I see. It seems like you may be one of the people that try to coerce relational models into nosql stores like Dynamo.

              Or course it’s possible. They even trick you into thinking it’s a good pattern by naming things “tables”.

              But if you’re using Dynamo to its fullest an ORM is not going to be able to replicate that into a relational store without some fundamental changes.

        • prof@infosec.pub
          link
          fedilink
          arrow-up
          0
          ·
          4 months ago

          While he advocates for it, that’s also a point that Martin brings up multiple times when he talks about his project “fitnesse”.

          Basically saying that they left it open how stuff can be saved, but the need has never arisen to actually pivot to a different system.

        • Tja@programming.dev
          link
          fedilink
          arrow-up
          0
          ·
          4 months ago

          In my 15 year career? Dozens. Maybe low hundreds. Depends what you work on. Oracle is not making any friends lately and a ton of companies a whole-sale migrating to Postgres, MongoDB, DynamoDB or some of the NewSQL contenders. It’s like 50% of the projects I’m involved in. Results are generally positive, with some spectacular wins (x3000 acceleration or x1000 lower costs) and a few losses.

      • marlowe221@lemmy.world
        link
        fedilink
        English
        arrow-up
        0
        ·
        edit-2
        4 months ago

        I generally agree with the idea that code should be as simple as it can be to accomplish the goal of the code… I just haven’t been convinced that Clean Code is the way to get there, necessarily. The book does contain some good advice , to be sure, but I wouldn’t call it universal by any means.

        I also think TDD is a very optimistic strategy that just doesn’t match up with reality terribly often.

        Actually, I think that’s what confuses me the most about all of Uncle Bob’s books. I’ve read a couple of them and thought, “All this sounds great but real world development just doesn’t seem to work that way.” Like, all of his advice is for best case scenarios that I certainly haven’t encountered in my career.

        I say confusing, because surely he’s been in the profession long enough to have seen the disconnect between what he’s preaching and real life, right???

  • Mia@lemmy.blahaj.zone
    link
    fedilink
    arrow-up
    0
    ·
    4 months ago

    I’m of the opinion that Uncle Bob did some massive damage to software development as a whole with that book.
    With that said, this is genuinely funny.

    • pfm@scribe.disroot.org
      link
      fedilink
      arrow-up
      0
      ·
      4 months ago

      I’d love to learn what that damage was. I often see complaints (sometimes also involving tech choices) but usually they’re not specific, so I’m always left wondering.

      • Mia@lemmy.blahaj.zone
        link
        fedilink
        arrow-up
        0
        ·
        edit-2
        4 months ago

        I’ve found it’s mostly two things: readability (ironically) and performance. I’ll describe a few crude examples, but I won’t get too much into specifics, otherwise I might as well write another book myself.

        The performance part is simple: its excessive reliance on polymorphism and the presence of several levels of abstraction just doesn’t allow for good code generation. I’ve seen 10x+ performance improvements by dropping all of the above, with often minimal loss in readability; on the contrary, oftentimes the code became more readable as well.

        The readability part is harder to explain; not only because it depends on the codebase and the problem at hand, but also on the coding style each programmer has (though in my opinion, in that particular case it’s the programmer’s problem, not the codebase’s).
        I like to think of codebases as puzzles. To understand a codebase, you need to piece together said puzzle. What I’ve found with Clean Code codebases is that each piece of the puzzle is itself a smaller puzzle to piece together, which isn’t ideal.

        Functions

        They should be small and do one thing

        I generally disagree, not because those ideas are wrong, but because they’re often too limiting.
        What often happens by following those principles is you end up with a slew of tiny functions scattered around your codebase (or a single file), and you are forced to piece together the behaviour they exhibit when called together. Your code loses locality and, much like with CPU cache locality, your brain has to do extra work to retrieve the information it needs every time it needs to jump somewhere else.
        It may work for describing what the code does at a high level, but understanding how it works to make meaningful changes will require a lot more work as a result.

        Don’t repeat yourself

        Once again, it makes sense in principle, but in practice it often creates more problems. I agree that having massive chunks of repeated code is bad, no questions about it, but for smaller chunks it may actually be desirable in some circumstances.
        By never repeating code, you end up with functions that are over-parameterized to account for all possible uses and combinations that particular code snippet needs to work with. As a result, that code becomes more complex, and the code that calls it does too, because it requires you to know all the right parameters to pass for it to do the right thing.

        Exceptions

        Exceptions are just bad. They are a separate, hidden control flow that you constantly need to be wary of.
        The name itself is a misnomer in my opinion, because they’re rarely exceptional: errors are not just common, but an integral part of software development, and they should be treated as such.
        Errors as values are much clearer, because they explicitly show that a function may return an error and that it should be handled.

        Classes, interfaces and polymorphism

        I have lots of gripes with object orientation. Not everything needs to be an object, and not everything needs to be polymorphic. There’s no need to have a Base64Decoder, much less having an IBase64Decoder or an AbstractBase64Decoder. Base64 only works one way, there are no alternative implementations, a function is enough.

        I’m a lot more on the data oriented side of the isle than the OO one, but I digress.
        Object orientation can be good in certain contexts, but it’s not a silver bullet.

        Encapsulation for the sake of it

        Let’s say you have something like this:

        class Point {
        	public float X, Y;
        }
        

        With the Clean Code approach, it magically becomes:

        class Point {
        	private float x, y;
        	
        	public float get_x() {
        		return this.x;
        	}
        	public float get_y() {
        		return this.y;
        	}
        	public void set_x(float x) {
        		this.x = x;
        	}
        	public void set_y(float y) {
        		this.y = y;
        	}
        }
        

        Why? Who the hell knows. It makes absolutely no tangible difference, it only makes your code longer and more verbose. Now, if a value needs validation, sure, but oftentimes this is just done regardless and it drives me insane.

        Abstract classes for everything!

        • “You’ll never know when you’ll need to add another implementation, right?”
        • “You don’t need to know the underlying implementation”

        The problem with wanting to create the most generalized code in advance is that you end up stuck in abstraction hell.
        You may as well not need the ability to have arbitrary implementations, but now you need to plan for that.

        Not only that, but it also makes reasoning about your code harder: how many times have you had to step through your code just to figure out what was being executed | just to figure out what particular concrete class was hiding behind an abstract class reference?
        I myself, way too many, and there was often no reason for that.

        Also, the idea that you shouldn’t know about the implementation is crazy to me. Completely encapsulating data and behaviour not only makes you miss out on important optimizations, but often leads to code bloat.

        There’s more but I’m tired of writing :)

        Take a look at these if you want more info or someone else’s view on the matter, I wholeheartedly recommend both:

        • bleistift2@sopuli.xyz
          link
          fedilink
          English
          arrow-up
          0
          ·
          4 months ago

          Thank you for linking the blog posts. They are a really good deterrent from Clean Code. I once thought I’d read it, but Fowler’s advice really is stupid.

          In case you’re wondering why I replied three times: “Do one thing” :)

        • Tja@programming.dev
          link
          fedilink
          arrow-up
          0
          ·
          4 months ago

          I generally agree, but there are some things that are oversimplified. Sure a point(x, y) can have public attributes, but usually business objects are a bit more complex: insurancePolicy, deliveryRoute, user, etc. Having some control over those is definitely something you want to implement, at the cost of some boilerplate.

          • Mia@lemmy.blahaj.zone
            link
            fedilink
            arrow-up
            0
            ·
            edit-2
            3 months ago

            Oh for sure. I have nothing against getters and setters when they’re justified, but in the case of bare fields with no validation like that example it’s just annoying.
            Also stuff like this just grinds my gears (oversimplified example again):

            class IntegerAdder {
                private int a, b;
                public IntegerAdder(int a, int b) {
                    this.a = a;
                    this.b = b;
                }
                
                public int get_sum() {
                    return a + b;
                }
            }
            

            Just make it a bloody function.
            You may say it’s silly, but I’ve genuinely found code like this in the wild. Not that exact code snippet of course but that was the spirit.

        • bleistift2@sopuli.xyz
          link
          fedilink
          English
          arrow-up
          0
          ·
          4 months ago

          Functions should be small and do one thing […] you end up with a slew of tiny functions scattered around your codebase (or a single file), and you are forced to piece together the behaviour they exhibit when called together

          I believe you have a wrong idea of what “one thing” is. This comes together with “functions should not mix levels of abstraction” (cited from the first blog entry you referenced). In a very low-level library, “one thing” may be sending an IP packet over a network interface. Higher up, “one thing” may be establishing a database connection. Even higher up, “one thing” may be querying a list of users from the database, and higher up yet again is responding to the GET /users http request. All of these functions do ‘one thing’, but they rely on calls to a few methods that are further down on the abstraction scheme.

          By allowing each function to do ‘one thing’, you decompose the huge problem that responding to an HTTP request actually is into more manageable chunks. When you figure out what a function does, it’s way easier to see that the function connectToDb will not be responsible for why all users are suddenly called "Bob". You’ll look into the http handler first, and if that’s not responsible, into getUsersFromDb, and then check what sendQuery does. If all methods truly do one thing, you’ll be certain that checkAuthorization will not be related to the problem.

          Tell me if I just didn’t get the point you were trying to make.

          • Mia@lemmy.blahaj.zone
            link
            fedilink
            arrow-up
            0
            ·
            edit-2
            4 months ago

            Yeah that was essentially what I was referring to (referring to your edit).

            I generally dislike stuff like (crappy example incoming):

            void do_stuff(int count, bool cond) {
            	function1(count);
            	function2(b);
            	function3();
            }
            
            void function1(int count) {
            	for (var i = 0; i < count; i++) {
            		...
            	}
            }
            
            void function2(bool cond) {
            	if (cond) { ... }
            	else { ... }
            }
            
            void function3() {
            	...
            }
            

            I’m not a fan of this kind of code fragmentation.
            If all those actions were related and it could have been just one thing, retaining a lot more context, then it should be one function imo.
            If by not splitting it it became massive with various disconnected code blocks, sure, but otherwise I’d much prefer being able to read everything together.

            If splitting the functions required producing side effects to maintain the same functionality, then that’s even worse.

            • flying_sheep@lemmy.ml
              link
              fedilink
              arrow-up
              0
              ·
              edit-2
              3 months ago

              Huh, I really like code like that. Having a multi-step process split up into sections like that is amazing to reason about actual dependencies of the individual sections. Granted, that only applies if the individual steps are kinda independently meaningful

              To adapt your example to what I mean:

              Baz do_stuff(int count, boolean cond) {
              	Foo part1 = function1(count);
              	Bar part2 = function2(cond);
              	return function3(part1, part2);
              }
              

              This allows you to immediately see that part1 and part2 are independently calculated, and what goes into calculating them.

              There are several benefits, e.g.:

              1. if there is a problem, you can more easily narrow down where it is (e.g. if part2 calculates as expected and part1 doesn’t, the problem is probably in function1, not function2 or function3). If you have to understand the whole do_stuff before you can effectively debug it, you waste time.
              2. if the function needs to be optimized, you know immediately that function1 and function 2 can probably run in parallel, and even if you don’t want to do that, the slow part will show up in a flame graph.
              • Mia@lemmy.blahaj.zone
                link
                fedilink
                arrow-up
                0
                ·
                3 months ago

                It really depends on the context frankly. I did say it was a crappy example ;)
                Try to read this snippet I stole from Clean Code and tell me if it’s readable without having to uselessly jump everywhere to understand what’s going on:

                public class SetupTeardownIncluder {
                  private PageData pageData;
                  private boolean isSuite;
                  private WikiPage testPage;
                  private StringBuffer newPageContent;
                  private PageCrawler pageCrawler;
                
                
                  public static String render(PageData pageData) throws Exception {
                    return render(pageData, false);
                  }
                
                  public static String render(PageData pageData, boolean isSuite) throws Exception {
                    return new SetupTeardownIncluder(pageData).render(isSuite);
                  }
                
                  private SetupTeardownIncluder(PageData pageData) {
                    this.pageData = pageData;
                    testPage = pageData.getWikiPage();
                    pageCrawler = testPage.getPageCrawler();
                    newPageContent = new StringBuffer();
                  }
                
                  private String render(boolean isSuite) throws Exception {
                     this.isSuite = isSuite;
                    if (isTestPage())
                      includeSetupAndTeardownPages();
                    return pageData.getHtml();
                  }
                
                  private boolean isTestPage() throws Exception {
                    return pageData.hasAttribute("Test");
                  }
                
                  private void includeSetupAndTeardownPages() throws Exception {
                    includeSetupPages();
                    includePageContent();
                    includeTeardownPages();
                    updatePageContent();
                  }
                
                
                  private void includeSetupPages() throws Exception {
                    if (isSuite)
                      includeSuiteSetupPage();
                    includeSetupPage();
                  }
                
                  private void includeSuiteSetupPage() throws Exception {
                    include(SuiteResponder.SUITE_SETUP_NAME, "-setup");
                  }
                
                  private void includeSetupPage() throws Exception {
                    include("SetUp", "-setup");
                  }
                
                  private void includePageContent() throws Exception {
                    newPageContent.append(pageData.getContent());
                  }
                
                  private void includeTeardownPages() throws Exception {
                    includeTeardownPage();
                    if (isSuite)
                      includeSuiteTeardownPage();
                  }
                
                  private void includeTeardownPage() throws Exception {
                    include("TearDown", "-teardown");
                  }
                
                  private void includeSuiteTeardownPage() throws Exception {
                    include(SuiteResponder.SUITE_TEARDOWN_NAME, "-teardown");
                  }
                
                  private void updatePageContent() throws Exception {
                    pageData.setContent(newPageContent.toString());
                  }
                
                  private void include(String pageName, String arg) throws Exception {
                    WikiPage inheritedPage = findInheritedPage(pageName);
                    if (inheritedPage != null) {
                      String pagePathName = getPathNameForPage(inheritedPage);
                      buildIncludeDirective(pagePathName, arg);
                    }
                  }
                
                  private WikiPage findInheritedPage(String pageName) throws Exception {
                    return PageCrawlerImpl.getInheritedPage(pageName, testPage);
                  }
                
                  private String getPathNameForPage(WikiPage page) throws Exception {
                    WikiPagePath pagePath = pageCrawler.getFullPath(page);
                    return PathParser.render(pagePath);
                  }
                
                  private void buildIncludeDirective(String pagePathName, String arg) {
                    newPageContent
                      .append("\n!include ")
                      .append(arg)
                      .append(" .")
                      .append(pagePathName)
                      .append("\n");
                  }
                }
                

                That’s what I was talking about.

        • bleistift2@sopuli.xyz
          link
          fedilink
          English
          arrow-up
          0
          ·
          4 months ago

          Exceptions are just bad. They are a separate, hidden control flow that you constantly need to be wary of. The name itself is a misnomer in my opinion, because they’re rarely exceptional: errors are not just common, but an integral part of software development

          They may be a part of software development, but they should not be common during the normal execution of software. I once read the hint, “if your app doesn’t run with all exception handlers removed, you are using exceptions in non-exceptional cases”.

          Throwing an exception is a way to tell your calling function that you encountered a program state in which you do not know how to proceed safely. If your functions regularly throw errors at you, you didn’t follow their contract and (for instance) didn’t sanitize the data appropriately.

          Errors as values are much clearer, because they explicitly show that a function may return an error and that it should be handled.

          I disagree here. You can always ignore an error return value and pretend that the “actual” value you got is correct. Ignoring an exception, on the other hand, requires the effort to first catch it and then write an empty error handler. Also (taking go as an inspiration), I (personally) find this very hard to read:

          res, error = try_something()
          if error {
            handle_the_error(error)
            return_own_error()
          }
          res2, error2 = try_something_else(res)
          if error2 {
            handle_other_error(error2)
            return_own_error()
          }
          res3, error3 = try_yet_something_else(res2)
          if error3 {
            handle_the_third_error(error3)
            return_own_error()
          }
          return res3
          

          This code mingles two separate things: The “normal” flow of the program, which is supposed to facilitate a business case, and error handling.

          In this example, on the other hand, you can easily figure out the flow of data and how it relates to the function’s purpose and ignore possible errors. Or you can concentrate on the error handling, if you so choose. But you don’t have to do both simultaneously:

          try {
            res = try_something()
            res2 = try_something_else(res)
            res3 = try_yet_something_else(res2)
            return res3
          } catch (e) {
            // check which error it is and handle it appropriately
            throw_own_exception()
          }
          
          • Mia@lemmy.blahaj.zone
            link
            fedilink
            arrow-up
            0
            ·
            4 months ago

            Also (taking go as an inspiration), I (personally) find this very hard to read

            Agreed. Go’s implementation of errors as values is extremely noisy and error prone. I’m not a fan of it either.

            You can always ignore an error return value and pretend that the “actual” value you got is correct.

            Then that’s a language design / api design issue. You should make it so you cannot get the value unless you handle the error.
            I’m of the opinion that errors should be handled “as soon as possible”. That doesn’t necessarily mean immediately below the function call the error originates from, it may very well be further up the call chain. The issue with exceptions is that they make it difficult to know whether or not a function can fail without knowing its implementation, and encourage writing code that spontaneously fails because someone somewhere forgot that something should be handled.

            The best implementation of errors as values I’ve seen is Rust’s Result type, which paired with the ? operator can achieve a similar flow to exceptions (when you don’t particularly care where exactly an error as occurred and just want to model the happy path) while clearly signposting all fallible function calls. So taking your example:

            try {
              res = try_something()
              res2 = try_something_else(res)
              res3 = try_yet_something_else(res2)
              return res3
            } catch (e) {
              // check which error it is and handle it appropriately
              throw_own_exception()
            }
            

            It would become:

            fn do_the_thing() -> Result<TheValue, TheError> {
            	res = try_something()?;
            	res2 = try_something_else(res);
            	res3 = try_yet_something_else(res2)?;
            }
            
            match do_the_thing() {
            	Ok(value) => { /*Do whatever*/ }
            	Err(error) => { /*handle the error*/ }
            }
            

            The difference is that you know that try_something and try_yet_something_else may fail, while try_something_else cannot, and you’re able to handle those errors further up if you wish.
            You could do so with exceptions as well, but it wasn’t clear.

            The same clarity argument can be made for null as well. An Option type is much more preferable because it forces you to handle the case in which you are handed nothing. If a function can operate with nothing, then you can clearly signpost it with an Option<T>, as opposed to just T if a value is mandatory.

            Exceptions are also a lot more computationally expensive. The compiler needs to generate landing pads and a bunch of other stuff, which not only bloat your binaries but also prevent several optimizations. C# notoriously cannot inline functions containing throws for example, and utility methods must be created to mitigate the performance impact.

        • ZILtoid1991@lemmy.world
          link
          fedilink
          arrow-up
          0
          ·
          3 months ago

          The “Don’t repeat yourself” mantra is also used with documentation, this leads to documentation which you first have to read and learn unless you frequently want to step into issues of the documentation assumed you read prior parts and didn’t just searched how to do XYZ.

          Also while I used the more clean code oriented XML DOM implementation for my D XML parser (or at least copied such code as it was abandoned by its original creator), I planned a much simpler system for my SDLang parser. While everything originates from the DLElement abstract class, I didn’t go overboard with the interfaces, etc.

    • Phegan@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      4 months ago

      Agreed. I found that many developers, in the pursuit of clean code, lost slight of some of the fundamentals principles of good code. I found that people were eschewing readability and modularity and calling it clean code.

      Clean code became the target, not the underlying principles and the reason why we needed clean code in the first place. It became an entirely new thing that aided in producing some of the worst code I’ve read.

      Oftentimes, when devs talk about “clean code” it’s a red flag for me in hiring. Some of the worst devs I’ve worked with have been clean code evangelists.

      • pfm@scribe.disroot.org
        link
        fedilink
        arrow-up
        0
        ·
        4 months ago

        I’m beginning to feel we’re no longer talking about Clean Code being bad, but about people following ideas they don’t understand, which is not related or caused to any particular book.

        • jecxjo@midwest.social
          link
          fedilink
          English
          arrow-up
          0
          ·
          edit-2
          3 months ago

          I think its less about not understanding and more that these concepts only work in unrealistic scenarios that aren’t real. It’s the same with Agile. They never address the actual issue and try to work around them which never works.

  • EnderMB@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    3 months ago

    Working in Ruby did 10x more to help me write clean code than reading Clean Code ever did.

    Many of the lessons drilled into me with Ruby (keep a consistent style, tests are cheap, keep your methods relatively small where possible, reduce nesting where possible) carry over nicely into other languages without needing to go through any OO bullshit.

    IMO, the best lesson around Clean Code is this: you’re not clever, write obvious code that works with as few tricks as possible.

    • Mia@lemmy.blahaj.zone
      link
      fedilink
      arrow-up
      0
      ·
      3 months ago

      I find this to be true for every new language I try out. Since every language has a different way of doing things and gives me a new perspective, in the long run they all end up improving my programming style as a whole. I always end up integrating the best parts of each into my next project when possible.

      Experience will always be more valuable than any set of rules these kind of books tout as “the way things are meant to be done”.