|
Robert C. Martin is a crank but that book helped me think more about how to chip away at horrible ball-of-mud legacy code without breaking it
|
#
?
Mar 11, 2021 15:41
|
|
|
|
| # ? May 13, 2024 12:51 |
|
|
Bob Martin sucks, he's sexist and a racist, don't give him money.
|
|
#
?
Mar 11, 2021 16:05
|
|
|
Jose Valasquez posted:Bob Martin sucks, he's sexist and a racist, don't give him money. Beyond this, while Clean Code has some good advice, it also has some absolutely dog poo poo advice. If you dogmatically follow Clean Code your code will be an unreadable mess. https://qntm.org/clean is a better anti-recommendation for Clean Code than I could give
|
|
#
?
Mar 11, 2021 16:25
|
|
|
Jose Valasquez posted:If you dogmatically follow [insert most things in software development] your code will be an unreadable mess. I still argue clean code is a book worth recommending, as long as you make it clear to the person that they should engage their brain and not just follow its rules blindly. Its principles are still great. The man himself though definitely is a poo poo , so I usually recommend people pick it up cheap 2nd hand or 'find' a pdf. You're likely to only read it once anyway. Mega Comrade fucked around with this message at 16:57 on Mar 11, 2021 |
|
#
?
Mar 11, 2021 16:51
|
|
|
I like clean code simply because it's the first and only book on coding guideljne I've read and it was useful to help me think about coding. Are there any other (better) books on this topic you guys would recommend?
|
|
#
?
Mar 11, 2021 17:09
|
|
|
I learned a lot from Clean Code when I read it starting my career and I still think it's useful for that level, even if all you do is reflect on why you disagree with what he says. If you think he says some birdbrained poo poo in Clean Code, though, you have got to check out The Clean Coder, his book of career advice. If i recall correctly he repeatedly argues that he should have been fired from several jobs early in his career, which, well,
|
|
#
?
Mar 11, 2021 17:11
|
|
|
There is no real consensus what the successor to clean code is yet, its been the book for so long people are hesitant. Its also not helped that most alternatives just don't tackle the issues in the same depth as clean code. However I do see 'A Philosophy of Software Design by John Ousterhout' popping up a lot and seems to be gaining traction. I haven't gotten around to it myself yet though.
Mega Comrade fucked around with this message at 17:19 on Mar 11, 2021 |
|
#
?
Mar 11, 2021 17:16
|
|
|
The problem with writing a successor to Clean Code is that ultimately what constitutes clean code is very much a matter of personal opinion. The world seems to have recognized that and now we focus mostly on team- or company-level style guides. Even if there is no right answer, there's value in getting everyone working on the same codebase to use the same formatting and style.
|
|
#
?
Mar 11, 2021 17:53
|
|
|
Yeah I really dislike it when people start talking about how code is "clean" or "not clean." It's just another way of saying "I like it"/"I don't like it." "Readability" is a similarly abused term, but at least the underlying concept there is salvageable.
|
|
#
?
Mar 11, 2021 18:39
|
|
|
There are actual metrics you can use to evaluate code and domain designs, but yeah "cleanliness" isn't really one of them. I usually lean towards looking at cyclomatic complexity and evaluating SAGE -- specialization, afference, generalization, efference.
|
|
#
?
Mar 11, 2021 18:46
|
|
|
The only thing I ever remember from Clean Code is the one about being able to read code from top to bottom; but then I always mix up whether he wants me to write the ‘main’ function first and the details later or the other way around (either could be appropriate depending on your particular file). I think the guy probably had a great time writing it, who doesn’t want to rant about bad code and present their own preferences as truth, but reading it is like getting a code review from someone with a stick up their arse. IMO Sandi Metz’s books show and explain the important bits of achieving pleasing readable code in a much friendlier and less nitpicky way for beginners.
|
|
#
?
Mar 11, 2021 19:09
|
|
|
There are definitely some parts that are geared towards being able to read and manage code without an IDE. But no one's doing that for any project of appreciable size nowadays, so why optimize for that use case?
|
|
#
?
Mar 11, 2021 19:14
|
|
|
12 rats tied together posted:cyclomatic complexity This is the big one for me. Realistically, if you have a 1000-line function, but at no point are you branching/looping/otherwise doing anything interesting, it is probably also very easy to understand, and breaking it up does nothing beyond separating context. Similarly, if you have a 25 line function, and 15 of those lines are control flow, it's time to consider the parable of The Armed Future Maintainer Who Knows Your Home Address.
|
|
#
?
Mar 11, 2021 19:45
|
|
|
ChickenWing posted:This is the big one for me. Realistically, if you have a 1000-line function, but at no point are you branching/looping/otherwise doing anything interesting, it is probably also very easy to understand, and breaking it up does nothing beyond separating context. Similarly, if you have a 25 line function, and 15 of those lines are control flow, it's time to consider the parable of The Armed Future Maintainer Who Knows Your Home Address. Depends on the person. If a method has 1000 lines, I'm going to lose track of what the previous 950 lines were doing unless there's some sort of abstraction. It's just the way my brain works when building mental models of code.
|
|
#
?
Mar 11, 2021 20:08
|
|
|
Cyclometric complexity is an okay metric but it has a lot of shortcomings, such as that it considers a switch over 20 enum cases and a 20-element if-else chain with lots of unrelated checks in the ifs to be equal.
|
|
#
?
Mar 11, 2021 20:09
|
|
|
The problem with Clean Code isn't that it doesn't have good advice, it's that the good advice is also sprinkled with a lot of bad advice, so you have to have enough experience already to tell what is good and what is bad. If you're already experienced enough to make those kinds of judgment calls and just want things to think about then I'm sure it's fine, but I wouldn't recommend it to a new engineer
|
|
#
?
Mar 11, 2021 20:14
|
|
|
Truman Peyote posted:If you think he says some birdbrained poo poo in Clean Code, though, you have got to check out The Clean Coder, his book of career advice. If i recall correctly he repeatedly argues that he should have been fired from several jobs early in his career, which, well, For maximum amusement read the first chapter of Clean Architecture. There's a bit in it where he demonstrates the efficacy of test-driven development by having one programmer write the same program six times in six days, alternating daily between using TDD and not using TDD. Using TDD is a good three minutes faster!
|
|
#
?
Mar 11, 2021 21:35
|
|
|
ultrafilter posted:The problem with writing a successor to Clean Code is that ultimately what constitutes clean code is very much a matter of personal opinion. The world seems to have recognized that and now we focus mostly on team- or company-level style guides. Even if there is no right answer, there's value in getting everyone working on the same codebase to use the same formatting and style. Eh, I don't agree to be honest. Clearly there are people who are better at writing readable and well-structured code than other people. I bet everybody has met someone who can't structure his code worth a drat and/or is horrible at naming his variable/functions. So this is a skill that people can learn and it's not entirely subjective. Whether Clean Code as a book is good is entirely a different question. Probably it isn't. But the world does need a good book that explains basic ideas such as "naming is really important", "code that is easy to test tends to be well designed and the other way around", "functions are great because you can give them a meaningful name", "try to use pure functions instead of relying on side effects when possible", etc. I'll take a look at A Philosophy of Software Design.
|
|
#
?
Mar 11, 2021 22:00
|
|
|
I recommend you actually do not read any of The Clean Architecture
|
|
#
?
Mar 11, 2021 22:01
|
|
|
Doom Mathematic posted:For maximum amusement read the first chapter of Clean Architecture. There's a bit in it where he demonstrates the efficacy of test-driven development by having one programmer write the same program six times in six days, alternating daily between using TDD and not using TDD. Using TDD is a good three minutes faster! my old boss used to love uncle bob, hence reading "The Clean Coder," and once he showed us a video of a 60-minute talk that he gave. The first 20 minutes were him talking about how if you have two parents, and they have four parents, and you keep going back, eventually there's more ancestors than there were alive at that time, so everyone is the product of *some* level of inbreeding e: i also do not approve of the familiarity of the name "uncle bob" Truman Peyote fucked around with this message at 02:06 on Mar 12, 2021 |
|
#
?
Mar 12, 2021 01:58
|
|
|
Yeah anyone who takes on the moniker Uncle is already loving creepy let alone all the racist MAGA poo poo he's now into.
|
|
#
?
Mar 12, 2021 02:26
|
|
|
Does every company not have an older dev who goes by uncle <name>?
|
|
#
?
Mar 12, 2021 04:17
|
|
|
FlowerRhythmREMIX posted:Does every company not have an older dev who goes by uncle <name>? "if you don't know who the older dev that everyone calls uncle is, it's probably you "
|
|
#
?
Mar 12, 2021 04:21
|
|
Truman Peyote posted:If you think he says some birdbrained poo poo in Clean Code, though, you have got to check out The Clean Coder, his book of career advice. If i recall correctly he repeatedly argues that he should have been fired from several jobs early in his career, which, well, It's also aggresively anti-worker. He argues that you should work overtime 20 hours per week for free, learning new skills, and never do that during working hours because a real professional doesn't steal time from their benevolent employer for personal development. SimonChris fucked around with this message at 09:27 on Mar 12, 2021 |
|
|
#
?
Mar 12, 2021 09:19
|
|
|
I don’t think he’s anti-worker - he’s strong on not doing overtime - so much as he’s pro- a certain kind of employee-employer relationship where you work hard and honestly and take an interest in the business, and in return your employer respects you, listens when you say no, and rewards you for your work. Almost nobody has this. He doesn’t even seem to have it in most of his anecdotes! The majority of us have relationships where it benefits your career far more to lie, half-rear end and schmooze, because you’re not going to be paid more if you work more. I think he’s just idealistic and old-fashioned more than malicious. (For example he advocates pairing even though it’s hell for the employee, purely because it’s good for productivity and quality. Screw the people involved, the tech comes first! Not because he loves the boss, but because he loves PRODUCTIVITY itself.) The really baffling thing to me is that his idea of practicing is katas, the point of which seems not to be engaging with new and varied toy problems, but to memorise keystrokes and mouse movements. I really do have better things to do with my weekend. Prism Mirror Lens fucked around with this message at 10:43 on Mar 12, 2021 |
|
#
?
Mar 12, 2021 10:34
|
|
|
Prism Mirror Lens posted:(For example he advocates pairing even though it’s hell for the employee, purely because it’s good for productivity and quality. Screw the people involved, the tech comes first! Not because he loves the boss, but because he loves PRODUCTIVITY itself.) Sorry, what? I like pairing. It's great for getting people up to speed with unfamiliar code. Even outside of a trainer/trainee situation, I've enjoyed it. I had one job where it was just me and one other person on a particular project, so we paired full time, switching off who was the keyboard toucher every couple of hours. We both knew the codebase in detail and were able to work through solutions in real time. Our office had a standing desk and a whiteboard so there was a lot of pacing around and scribbling as well as coding. It was one of the best job experiences I've had. The kata thing sounds idiotic.
|
|
#
?
Mar 12, 2021 14:06
|
|
|
vonnegutt posted:Sorry, what? I like pairing. It's great for getting people up to speed with unfamiliar code. This sounds like a great learning opportunity. I've always wanted to have like an monthly hour meeting to sit down and group troubleshoot a ticket, so everyone can get an opportunity to learn others' process. My experience of software engineering culture has often been one of secrecy and apprehension at sharing code (code review mitigates a lot of this).
|
|
#
?
Mar 12, 2021 14:39
|
|
|
Pairing is great if it is with someone you like and work well with, and like pulling teeth with anyone else.
|
|
#
?
Mar 12, 2021 15:05
|
|
|
Encouraging pairing is good, enforcing pairing sounds like a nightmare.
|
|
#
?
Mar 12, 2021 16:53
|
|
|
Over the shoulder pair programming causes me to lose all ability to type or think clearly. Pair (or more) debugging and problem solving I've found to be very useful, however.
|
|
#
?
Mar 12, 2021 17:12
|
|
|
A former colleague of mine once worked at a place with enforced code pairing that was very frequent if not daily (don’t remember) and he said that it was miserable and exhausting and made a whole lot worse by his assigned coding partner being an antisocial weirdo who barely acknowledged him much less talked through the code with him. Yes, definitely a nightmare. I’ve found as-needed ad hoc code pairing, especially for troubleshooting, really beneficial. It’s one of the things I miss about being in the office. We can still screen-share and whatnot, but it’s not the same as being in the same room, looking at the same screen and trading off the keyboard and figuring poo poo out together. I also miss whiteboarding. I’ve been tempted to pick up a Wacom or something so I can do live sketching during brainstorming meetings because I’m tired of drawing things on paper and holding them up to my screen.
|
|
#
?
Mar 12, 2021 17:41
|
|
|
Queen Victorian posted:I also miss whiteboarding. I’ve been tempted to pick up a Wacom or something so I can do live sketching during brainstorming meetings because I’m tired of drawing things on paper and holding them up to my screen. Yeah, this is one of the only things I actually miss being from being in the office. I have a Wacom, but it's just inconvenient enough that I avoid busting it out when I could, unlike the whiteboard I used to have right behind my desk.
|
|
#
?
Mar 12, 2021 17:47
|
|
|
chglcu posted:Over the shoulder pair programming causes me to lose all ability to type or think clearly. Pair (or more) debugging and problem solving I've found to be very useful, however. One's ability to perform any computer task is inversely proportional to the number and skill level of the people watching you perform that task
|
|
#
?
Mar 13, 2021 02:57
|
|
|
12 rats tied together posted:There are actual metrics you can use to evaluate code and domain designs, but yeah "cleanliness" isn't really one of them. I usually lean towards looking at cyclomatic complexity and evaluating SAGE -- specialization, afference, generalization, efference. The worst is when people put cyclomatic complexity or any of these metrics in their linter, and some random small change is the one that breaks the rule and requires a refactoring for no good reasons.
|
|
#
?
Mar 13, 2021 14:25
|
|
|
I'm getting deja vu, I think I remember reading similar responses when a bunch of posters reminded me that pair programming can be a nightmare. I still haven't been in a place that uses it, maybe for the best apparently!
|
|
#
?
Mar 13, 2021 15:13
|
|
|
On a different topic: how common is it for corporate employers to literally take 6-8 months to roll out each annual MacOS update? We just got Catalina a few months ago and maybe we will get Big Sur sometime in 2021? It’s a bit ridiculous and really messes with new hardware buys which are going to be on the new OS version regardless.
|
|
#
?
Mar 13, 2021 17:09
|
|
|
smackfu posted:On a different topic: how common is it for corporate employers to literally take 6-8 months to <do anything> Very
|
|
#
?
Mar 13, 2021 17:11
|
|
|
smackfu posted:On a different topic: how common is it for corporate employers to literally take 6-8 months to roll out each annual MacOS update? We just got Catalina a few months ago and maybe we will get Big Sur sometime in 2021? It’s a bit ridiculous and really messes with new hardware buys which are going to be on the new OS version regardless. I've seen this a few times at my employer because each update breaks the mandatory virus scanner for a few months
|
|
#
?
Mar 13, 2021 17:17
|
|
|
Our company is data driven but I didn't realize that the data source is a random number generator
|
|
#
?
Mar 13, 2021 17:40
|
|
|
|
| # ? May 13, 2024 12:51 |
|
|
New Yorp New Yorp posted:Depends on the person. If a method has 1000 lines, I'm going to lose track of what the previous 950 lines were doing unless there's some sort of abstraction. It's just the way my brain works when building mental models of code. The keys to whether or not this is an optimum way to structure code hinge on:
A reasonable analog in the physical world is IRS Form 1040. It's a hugely complicated thing, and there's two or three spots where you might optionally break out into a subform, but the process of filling it out would be way more complicated if it was carved out by default into a pile of forms that had to all be coalesced together. I think "single giant method" is a completely valid pattern for representing many workflows, but if there's too many of those, the business has something loving wrong with it. Vulture Culture fucked around with this message at 18:25 on Mar 13, 2021 |
|
#
?
Mar 13, 2021 18:23
|
|
