|
I'm seven years into my current job and I'm certainly less passionate about it than I once was but I still enjoy a lot of the work and it's actually nice being less emotionally invested in work.
|
#
?
Mar 7, 2021 05:22
|
|
|
|
| # ? May 17, 2024 21:48 |
|
|
ChickenWing posted:IDK I've never really understood this - if I have a ButtService and I'm doing a lot of butt-related functionality, why wouldn't it get to 1k+ lines? IDEs take a lot of the pain out of long files. At this point Farting, Pooping, and Sex could all probably be their own classes with a reduced public surface area. Even if those classes are only ever used by ButtsService it still makes the code far more maintainable. i.e. you can make changes to private methods in the Pooping module without having to worry that you're breaking something that Farting relies on. And you can assign one team member to work on Farting and Pooping while a third works on Sex and theoretically your merges should be a lot easier. Speaking of Butts with large public surface areas, has anyone heard from OP's mom lately
|
|
#
?
Mar 7, 2021 05:39
|
|
|
prom candy posted:Just venting but how do you let a file get to 1300 lines and not think "you know maybe some of this functionality doesn't belong here" Someone has never seen the 20,000 line php function...
|
|
#
?
Mar 7, 2021 06:58
|
|
|
ChickenWing posted:IDK I've never really understood this - if I have a ButtService and I'm doing a lot of butt-related functionality, why wouldn't it get to 1k+ lines? IDEs take a lot of the pain out of long files. Beside the better answer about test surface and stuff that prom candy answered, why stop at 1300 lines ? Why stop at 2k or at 20k lines ? Why not put all 500k lines of codes in a single file ? You have to be able to think about concept and break them down into smaller parts, that's just part of what we do and how you keep things clean.
|
|
#
?
Mar 7, 2021 17:01
|
|
|
Jealous of everyone itt that hasn't gotten fed up with their manager/management and left every job at year three.
|
|
#
?
Mar 7, 2021 17:15
|
|
|
MadFriarAvelyn posted:Jealous of everyone itt that hasn't gotten fed up with their manager/management and left every job at year three. Wow look at the careerist over here who's ever made it to year three of a job.
|
|
#
?
Mar 7, 2021 17:47
|
|
|
https://twitter.com/d_feldman/status/1368036521878515712
|
|
#
?
Mar 7, 2021 22:56
|
|
|
If you think a minimap is a good editor/ide feature you are the problem (yes I understand some people have to read others code or are writing special stuff on old poo poo)
|
|
#
?
Mar 7, 2021 23:54
|
|
|
i mean some people have lovely eyes no, shittier than you're thinking shittier
|
|
#
?
Mar 8, 2021 06:42
|
|
|
Sistergodiva posted:If you think a minimap is a good editor/ide feature you are the problem (yes I understand some people have to read others code or are writing special stuff on old poo poo)
|
|
#
?
Mar 10, 2021 05:04
|
|
|
I think the point is if your files are routinely long enough to benefit from minimap your files are too long.
|
|
#
?
Mar 10, 2021 05:33
|
|
|
prom candy posted:I think the point is if your files are routinely long enough to benefit from minimap your files are too long. That seems a bit dogmatic. Files should be as long as they need to be, having stuff in the same file is just a way to organize complexity. Ideally all the things that are closely related should be close to each other and things that are unrelated to each other should be far away. If you're performing a complex calculation you'll often have many things that are closely related to each other but are unrelated to the rest of the system, in which case keeping them in the same file/function makes a lot of sense. If you're writing a web app you'll often have a bunch of things that are sort of related to each other, where lots of small functions are nice. The research I've read puts the "this is too long" point around 150 lines, where most people have problems keeping the entire thing in their head but stuff that's essentially a script can be longer without too much worry.
|
|
#
?
Mar 10, 2021 05:43
|
|
|
NovemberMike posted:That seems a bit dogmatic. Files should be as long as they need to be, having stuff in the same file is just a way to organize complexity. Ideally all the things that are closely related should be close to each other and things that are unrelated to each other should be far away. If you're performing a complex calculation you'll often have many things that are closely related to each other but are unrelated to the rest of the system, in which case keeping them in the same file/function makes a lot of sense. If you're writing a web app you'll often have a bunch of things that are sort of related to each other, where lots of small functions are nice. The research I've read puts the "this is too long" point around 150 lines, where most people have problems keeping the entire thing in their head but stuff that's essentially a script can be longer without too much worry. I'd say that if you're doing complex calculations, each individual piece of the complex calculation should be broken apart into something that can be easily isolated and unit tested so that you can compose the entire complex calculation engine out of small, well-tested pieces, not crammed together because they're related.
|
|
#
?
Mar 10, 2021 06:19
|
|
|
New Yorp New Yorp posted:I'd say that if you're doing complex calculations, each individual piece of the complex calculation should be broken apart into something that can be easily isolated and unit tested so that you can compose the entire complex calculation engine out of small, well-tested pieces, not crammed together because they're related. You'd think so but this was studied pretty extensively in the 80s and 90s and this causes higher defect rates, take longer to refactor and you're more likely to introduce defects when you refactor. It's counter to what the clean code gang started saying in the 2000s but as far as I've been able to tell none of that was actually based on empirical studies, just what they personally felt was cool. I'll try to scrounge up some of the studies again.
|
|
#
?
Mar 10, 2021 07:07
|
|
|
https://softwarebyscience.com/very-short-functions-are-a-code-smell-an-overview-of-the-science-on-function-length/ has some of it, although I last looked at this probably 3-4 years ago and it's not exactly the same datasets. http://number-none.com/blow/john_carmack_on_inlined_code.html is a reasonable exploration of a possible why. I'm not trying to make a strong claim here and I tend to write shorter functions because my coworkers like them but the thing I've found interesting is that I've never seen anything empirical that gives a strong preference for short functions, only subjective arguments.
|
|
#
?
Mar 10, 2021 07:16
|
|
|
Files should be split into multiple files when doing so makes them easier to navigate. This does not inherently happen at any specific line count. I've worked with files in the thousands of lines which got worse to work with when they were split into multiple files. Usually things like tests and build scripts where it's 500 ten-line things with no inherent ordering or grouping, so the only non-arbitrary division is one long file or five hundred tiny files.
|
|
#
?
Mar 10, 2021 07:57
|
|
|
NovemberMike posted:https://softwarebyscience.com/very-short-functions-are-a-code-smell-an-overview-of-the-science-on-function-length/ has some of it, although I last looked at this probably 3-4 years ago and it's not exactly the same datasets. http://number-none.com/blow/john_carmack_on_inlined_code.html is a reasonable exploration of a possible why. I'm not trying to make a strong claim here and I tend to write shorter functions because my coworkers like them but the thing I've found interesting is that I've never seen anything empirical that gives a strong preference for short functions, only subjective arguments. Very interesting, thanks for posting. I have definitely encountered code that smells "overly delegated" where every method has one small block or conditional of just a few lines. It is extremely difficult to read, reason through and even trace due to the multiple levels of context obfuscating the details of what you are really doing at any given point in time.
|
|
#
?
Mar 10, 2021 17:25
|
|
|
Not a dev but I've worked closely enough with good "clean code" leads and they stressed you should put what makes sense ahead of all the rules. Like everything: cargo cult adoption and rigid legalism is not the way to go.
|
|
#
?
Mar 10, 2021 17:34
|
|
|
When a merge request is undergoing review, it's totally fine to point out that the commits are a mess and should be rewritten. Maybe a few things are happening in that merge request that should be logically separated instead of squashed, sure. Is it reasonable that a 30 line change, already revised from 20 stupid commits to 3 tidy ones, should be rewritten again so that every single revision in the history would be correct and deployable before merging?
|
|
#
?
Mar 10, 2021 18:02
|
|
|
The rule there is usually that every commit of the target branch should be deployable, and yeah that is absolutely reasonable to request. If you're squashing or otherwise merging such that in the target branch HEAD is all of your changes and HEAD~1 is none of your changes, no that's totally unreasonable.
|
|
#
?
Mar 10, 2021 18:15
|
|
|
NovemberMike posted:That seems a bit dogmatic. Files should be as long as they need to be, having stuff in the same file is just a way to organize complexity. Ideally all the things that are closely related should be close to each other and things that are unrelated to each other should be far away. If you're performing a complex calculation you'll often have many things that are closely related to each other but are unrelated to the rest of the system, in which case keeping them in the same file/function makes a lot of sense. If you're writing a web app you'll often have a bunch of things that are sort of related to each other, where lots of small functions are nice. The research I've read puts the "this is too long" point around 150 lines, where most people have problems keeping the entire thing in their head but stuff that's essentially a script can be longer without too much worry. Thank you, I couldn't agree more. I hate this insistence that "no file should be longer than x lines" or "no function should be longer than y lines." The way you organize your code sends a signal; if you start breaking things up that logically belong together just to get under some arbitrary line limit you're going to be sending confusing signals. Being forced to jump around between files/functions can really increase the cognitive burden of trying to understand new code.
|
|
#
?
Mar 10, 2021 18:50
|
|
|
HappyHippo posted:I hate this insistence that "no file should be longer than x lines" or "no function should be longer than y lines." Is anyone here actually saying that? All I'm saying is that if you consistently have giant files and giant functions you probably aren't putting enough thought into what's related and what isn't related. Especially if you're working in a framework that's prone to having functionality dumping grounds and you never do the work to learn how to avoid them.
|
|
#
?
Mar 10, 2021 18:59
|
|
|
If I have to scroll up and down to read an entire function, it's too long 
|
|
#
?
Mar 10, 2021 19:06
|
|
|
NovemberMike posted:I've never seen anything empirical that gives a strong preference for short functions, only subjective arguments. I find this is also the case for a lot of software development. Maybe functional programming truly is better for a lot of situations but the people making that argument rarely cite data for that position.
|
|
#
?
Mar 10, 2021 19:08
|
|
|
That data is really hard to come by, and even once you have, whether functional programming is better depends a lot on how you define "better".
|
|
#
?
Mar 10, 2021 19:12
|
|
|
prom candy posted:Is anyone here actually saying that? All I'm saying is that if you consistently have giant files and giant functions you probably aren't putting enough thought into what's related and what isn't related. Especially if you're working in a framework that's prone to having functionality dumping grounds and you never do the work to learn how to avoid them. New Yorp New Yorp posted:I'd say that if you're doing complex calculations, each individual piece of the complex calculation should be broken apart into something that can be easily isolated and unit tested so that you can compose the entire complex calculation engine out of small, well-tested pieces, not crammed together because they're related. Or maybe this post right below yours qsvui posted:If I have to scroll up and down to read an entire function, it's too long Of course this isn't the only place this discussion has come up. Right there in one of NovemberMike's links, there's a quote from Clean Code: quote:The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that. Functions should not be 100 lines long. Functions should hardly ever be 20 lines long Once I read a discussion where someone was insisting that you should never nest loops. When someone asked about looping over two dimensions, this person insisted that you should take the inner loop and split it into it's own function. Give me a break.
|
|
#
?
Mar 10, 2021 19:18
|
|
|
HappyHippo posted:I mean the whole discussion started with "1300 lines is too long." And when people push back with "sometimes that functionality is related" they get replies like this: That wasn't my read of it, personally. It's absolutely important to break down problems into smaller problems that can be understood separately, not doing this is totally just writing bad code. There wasn't anything in the post that implied, to me, that these decoupled sub-problems need to be in different files. They should totally go in the same file. e: the never nesting loops guy, and the rest of your examples, are totally deranged, though. 12 rats tied together fucked around with this message at 19:42 on Mar 10, 2021 |
|
#
?
Mar 10, 2021 19:40
|
|
|
12 rats tied together posted:
Yeah, I don't necessarily care about file length, although certainly a long enough file can be onerous to navigate. I definitely do care about function length. Declaring a hard and fast rule about exact size is ridiculous, but you'll pretty naturally fall into having short, concise functions and relatively small individual files if you're adhering to the single responsibility principal and factoring code so that it's testable and composable instead of being monolithic. Like, in the case of our theoretical 1500 line function, unless 1200 of those lines are completely static boilerplate, I can almost guarantee you it's difficult to test and will be hard to extend without breaking unrelated existing tests all over the place. New Yorp New Yorp fucked around with this message at 19:49 on Mar 10, 2021 |
|
#
?
Mar 10, 2021 19:45
|
|
|
For me, I wouldn't say function length is a problem in itself, it's more how much you need to mentally keep track of to understand what's going on. Long functions as I frequently see them written tend to introduce more cognitive load due to having to remember what the hell happened however many lines back, but they don't necessarily have to if it's just a long sequence of simple operations or something.
|
|
#
?
Mar 10, 2021 19:50
|
|
|
chglcu posted:For me, I wouldn't say function length is a problem in itself, it's more how much you need to mentally keep track of to understand what's going on. Long functions as I frequently see them written tend to introduce more cognitive load due to having to remember what the hell happened however many lines back, but they don't necessarily have to if it's just a long sequence of simple operations or something. I think it depends a lot on how an individual builds mental models of things. Which is part of why this isn't going to ever really be a fruitful discussion because everyone's brain works a little bit differently and we can only try to shoot down the middle and come up with guidelines that usually work for most people. I'm incapable of visualizing things, I rely entirely on internal monologue. I've known other people who have no internal monologue and can't fathom how I process information. I'm going to inevitably find code written in a way that maps into my more narrative way of modeling concepts to be "better" and more intuitive than something written in a way that maps better to thinking about things more visually. In summary the human brain is a land of contrasts. Thank you.
|
|
#
?
Mar 10, 2021 19:59
|
|
|
Agreed, and I'd also say that it varies based on problem domain. I worked on a game server where the code responsible for "what happens when a player uses an ability" is basically a series of 20,000 LoC switch case statements. I absolutely would not rewrite it any other way, but the structure is extremely simple to understand for anyone doing work on the game because everyone arrives at this file/ these statements with the mindset of "I need to adjust what happens when skill id is 1234, I will now search for skill id 1234". In an alternate domain this pattern would result in the worst MVC app, for example, that it is possible to create.
|
|
#
?
Mar 10, 2021 20:05
|
|
|
HappyHippo posted:Of course this isn't the only place this discussion has come up. Right there in one of NovemberMike's links, there's a quote from Clean Code: That assertion about never nesting loops is also from Clean Code.
|
|
#
?
Mar 10, 2021 21:54
|
|
|
Doom Mathematic posted:That assertion about never nesting loops is also from Clean Code. 
|
|
#
?
Mar 10, 2021 22:19
|
|
|
ultrafilter posted:That data is really hard to come by, and even once you have, whether functional programming is better depends a lot on how you define "better". Of course, it's not like there was overwhelming empirical evidence that persuaded everyone to start using OOP so I don't even know if any of this matters.
|
|
#
?
Mar 10, 2021 22:21
|
|
|
I personally love clean code. It's probably my favourite programming book. I break the rules of the book all the time. But when I do I do it knowingly and with justification. Even though there are many rules I disagree with, it made me think about how I write code in a way I never had done before and I generally believe it made me a better developer.
|
|
#
?
Mar 10, 2021 22:34
|
|
|
clean code has lots of good guidelines, but it's not the bible
|
|
#
?
Mar 10, 2021 23:47
|
|
|
New Yorp New Yorp posted:I think it depends a lot on how an individual builds mental models of things. Which is part of why this isn't going to ever really be a fruitful discussion because everyone's brain works a little bit differently and we can only try to shoot down the middle and come up with guidelines that usually work for most people. I'm incapable of visualizing things, I rely entirely on internal monologue. I've known other people who have no internal monologue and can't fathom how I process information. I'm going to inevitably find code written in a way that maps into my more narrative way of modeling concepts to be "better" and more intuitive than something written in a way that maps better to thinking about things more visually. yeah this is the thing, realistically Code is communication, and everyone has different modes of communication. The communication strategy that works for one team may be different than the one for another, hence why everyone who tries to say "thou shalt not write functions more than 20 lines long" is doomed to be nitpicked into oblivion forever. Basically, Xguard86 posted:Like everything: cargo cult adoption and rigid legalism is not the way to go. also qsvui posted:If I have to scroll up and down to read an entire function, it's too long  works on my pc
|
|
#
?
Mar 11, 2021 03:12
|
|
|
ChickenWing posted:
|
|
#
?
Mar 11, 2021 03:29
|
|
|
Woebin posted:This is also great fun when your code base frequently has 200+ characters on a line. The only thing worse than having to scroll up and down to read a function is having to scroll horizontally. That's why you have one portrait and one landscape!
|
|
#
?
Mar 11, 2021 03:39
|
|
|
|
| # ? May 17, 2024 21:48 |
|
|
Mega Comrade posted:I personally love clean code. It's probably my favourite programming book. I break the rules of the book all the time. But when I do I do it knowingly and with justification. Even though there are many rules I disagree with, it made me think about how I write code in a way I never had done before and I generally believe it made me a better developer. Same, I honestly contribute that book to being a huge part of why folks at my current gig consider me a "senior dev". I definitely don't feel like one, but I think the book does a good job of introducing you to ways of thinking about writing code that lead to better overall organization/cohesiveness. There were absolutely times when I felt like he had gone too far off the deep end of clean code, but I think if you're going to write a book like that, you have to be a little extra obsessive and opinionated. You take what seems reasonable and valuable, and you let the rest simmer in the back of your mind. Highly recommend it.
|
|
#
?
Mar 11, 2021 07:38
|
|
