I don't understand why a hobby project for a few people warrants what is essentially a takedown post.There is a ton of open source projects that are not needed. People do them for all sorts of reasons. Live and let live.
This is such a tired argument. It's been 20 years. You don't think other OS's have had the opportunity?
The fact is, Windows is still king today because of backwards-compatibility and nothing else. No other OS has taken this as seriously. Certainly not Apple. And not Linux either.
You can still run DOS programs on Windows today. And companies do. I personally know of software originally written in the 80's and with many legacy components from that time still running on modern versions of Windows Server.
Companies don't take backwards-compatibility seriously. And if you're constantly breaking things, people are not going to trust your product for serious use to be relied on. It's really not that complicated.
Not to mention the developer tools are second to none. You may not like .Net, or you may have some problem with how Microsoft did business 20 years ago (get over it). But Visual Studio is hands down, without question, the best IDE on the market. And Visual Studio Code is the best text editor. And now, with their open source efforts, it just keeps getting better.
(Yes, I know that's not Apple's intended market, you don't have to tell me. The point still stands. Windows is popular today because of a herculean effort by Microsoft over the years to ensure backwards-compatibility. And yes, I know it's not perfect. You don't have to tell me that either. It's always the same tired arguments. And at the end of the day, the point still stands and no other OS has risen up to take Windows crown. And no, this year is not finally going to be the year of the Linux desktop. Next year either. Or the year after that. It's not going to happen. Get over it.)
> You don't think other OS's have had the opportunity?
For most non-technical people that didn't separate the concept of OS and hardware, there was no opportunity. Even if you were one of those technical people who bought a PC, wiped the hard drive and installed Linux, you still paid the Microsoft tax, which the OEM had to pass on to you in order to sell Windows at all.
It's not a tired argument because the ramifications of that action are still relevant today.
> Windows is still king today because of backwards-compatibility and nothing else.
IE11 is a perfect example of why this is a bad thing.
The fact that people were able to use Office at home and at work, and Office became a strong defacto standard for documents due to the substrate of Windows being ubiquitous, also had a lot to do with it.
> the point still stands and no other OS has risen up to take Windows crown.
The Windows crown is irrelevant in a mostly-mobile-and-server world. Why did Windows 8, 8.1, and 10 try so desperately to force mobile UI on a desktop experience? Why does Windows 10X look more like a Google Chrome UI than anything else?
I don't think that's true. I've never heard that about any other industry. Certainly not about janitorial work. Doctors curing a patient, lawyers winning a big case, secretaries keeping the schedule up to date, teachers with kids who pass their tests, truck drivers who deliver on time. all of that is plainly visible. IT is a field in which few people see the results or understand the effort required.
it's true of any industry or organizational structure that is considered a cost center.
As for your examples, those are all boolean - they either do it successfully or they don't, and if they do, it's what they are paid for, and if they don't, they catch hell. There is nothing intrinsic about IT that differs.
This is more prolific in software than just Y2K. At a company I work with, if everything is going smoothly and things are working, devs get a ton of crap for not getting more done, no matter the pace and productivity. Of course they get crap when things aren't working also.
When people don't understand something, they can't tell the difference between a lot of effort to make something work smoothly and "it's clearly not that big of a deal"
The Democrats could pack universal single payer healthcare into this bill and it would still pass. It would be political suicide for Republicans and Trump to block it. They would of course scream about the Democrats playing politics, but they do that about everything already, so what's new. The Democrats would be able to say they tried to help the country in a time of crisis and were blocked. It would be a win-win for Democrats.
Disclaimer: I am an independent and don't think Medicare for all is a good idea. Still though.
Not to disregard your own experience, but I too am old enough to remember the start of mobile phones, and no one I ever knew thought they were dorky. Douchy maybe, but that was mostly bc the early adopters were wealthy businessmen and finance jerks (no offense to anyone if you are one). But not dorky.
Why do they have to? I have that drive, but my wife is perfectly happy with a calm, comfortable, stress-free life. And in fact it helps to bring me back down to Earth sometimes also.
There's nothing wrong with wanting a life that free. In fact it's oftentimes admirable. Especially at times when I'm wound so tight I feel like I could pop.
If you're choosing a partner based solely on whether they want to be the next Elon Musk or not, you're doing yourself a serious disservice.
And if you really ask those questions to every potential date, you should stop, because dude, wtf?
Wow, I think you really misunderstood me. I'm not saying anyone has to do anything, I just said it's really inspiring to see people that are passionate, and are driven and motivated about something. And I want people like that in my life.
I'm not saying I want an Elon Musk for a partner, I'm saying it's inspiring, and I'm drawn to people that actually have a purpose and a reason to get out of bed, and they're striving for something. Maybe it's take a month off to ski tour around Mt. Logan this spring. Maybe it's sail around the Northwest passage, or maybe it's learning a new language. Maybe it's getting up early every day to do Yoga.
Anything, really.
I'm just saying I feel like a lot of people these days have nothing that they're striving for. They just go to work, and go home, and aren't even particularly happy about it. If you asked them what the point is they don't even have an answer. If you ask them what they will have achieved in 5 or 10 years, they have nothing. They're not even trying to do anything.
> Especially at times when I'm wound so tight I feel like I could pop.
It's a mistake to think that to be driven and passionate and motivated about something also means you have to be wound tightly. I've never spent time with anyone that is wound tightly, and I can't imagine how difficult that would be.
EDIT: Replying to your comment lower down - I absolutely DO NOT ever ask anyone what their plan to change the world is, and I never said anything like that above. I ask them what they're passionate about, and what they're striving towards. That doesn't have to be change the world.
The question posed was why do they Have to? Not why Should they.
Of course we need people driven to move society forward. But there is a stigma in modern society it seems around people who are perfectly happy being who they are and not "striving to be great". And that's ridiculous.
The previous poster asks all his potential dates, with what seems to be a fairly heavy helping of disdain for the "wrong answer", what their plan to change the world is.
Why does it matter? You go change the world. Let your spouse or your friends or your colleagues be content with not changing the world and just be happy living in it.
I'm not saying this is wrong or right, but perhaps some people feel everyone has a duty to do something meaningful to push society forward, otherwise they are essentially free-riding on everyone else's sacrifices.
And that something may very well be as broad a goal as "do your very best, everyday".
Sure, you can't force people to see the world through that same lens, but you can certainly pick partners based on traits which you admire, ambition / grit presumably being one of such traits.
I'm not. I'm just judging him for doing so. Which is wrong. I shouldn't have phrased it like that. I guess that stigma in society around people who are perfectly happy being happy and don't feel the need to "be great" is sensitive to me because my wife constantly receives a lot of crap for it.
So you be you, previous poster. Just don't look down on others who don't want to change the world.
In my opinion RuboCop is too strict. Every code standard analyzer takes some tweaking to get it set up for a particular project and team standards, but RuboCop needs changing of a ton of rules to make it even usable in a reasonable fashion.
I love it because it brings some order to a meta-everything world, but it'd be nice if it came with a reasonable set of rules by default
In my opinion the rules about requiring or forbidding parentheses are fairly arbitrary.
Sometimes it's really nice to fit three panes of code on a single laptop screen. Long lines can also indicate a code smell. It's ironic that one of the first things most teams change is the 80 character line length.
Yup. `conditional or return fallbackValue`. Rubocop desperately wants to change this to `conditional || return fallbackValue` but that's just.... not a thing.
The thing about that is, what's reasonable for you and your team is not always reasonable for me and my team.
Case and point, 80 character line limit: this was a reasonable limit when command lines were not usually rendered inside of high-res framebuffers, I have my font set to 12 point M+ font, which is a narrow width font, so my terminals are set to open at 180 characters wide and it only takes up half the width of my screen.
Most of the members of my team don't use this font, or even the same terminal, so I think that a 110 character limit is a good compromise, ...but I don't work alone, and so if we're going to set a standard, it should be a discussion and we should all have input before it's agreed to.
On the other hand you have tools like Rufo (or prettier, or gofmt) where these kinds of discussions are considered as wasteful and inviting unnecessary conflict about the color of the bike shed. There's a strong argument to be made that there is a reasonable default for standards, and it follows that we all should use the same standards as everyone else, and be glad that there's only one standard to worry about!
Rubocop is a much bigger tool than Rufo. I am glad, personally, that the developers of these tools talk to each other, and in some cases they have made efforts to make sure the defaults of both tools do not step on each other, which would make it impossible to use the two slightly orthogonal tools together on the same project. (I hope my team will find the means to adopt one or both of these tools soon!)
80 characters is nice for side by side buffers. Also, lines that are too long horizontally are difficult to scan (especially if they are much longer than the lines around them) and can benefit from some work on vertical layout.
> How much time do developers spend on side by side buffers?
In my case: all the time. On my desktop (which has a large display) I often tend to have 3-4 vertical buffers open. Being able to fit all my code in those buffers is a godsend.
I know this is a bit of a rare condition, but I have very sensitive eyes, so I need to work on a single small laptop screen with decently large font size, otherwise I get eyestrain and I'm out for a week. So when I have two emacs windows open even 80 characters wraps around. I put up with it, but when a codebase has something like 70 or less characters per line I find it much easier to develop in.
It's my default mode of working. Even in a statically-typed language (I mostly write Haskell these days), I often have one buffer for the things I'm working on, and 1..N buffers of references or parallel changes.
> Case and point, 80 character line limit: this was a reasonable limit when command lines were not usually rendered inside of high-res framebuffers, I have my font set to 12 point M+ font, which is a narrow width font, so my terminals are set to open at 180 characters wide and it only takes up half the width of my screen.
Use three terminals? No, seriously, you can pack even more information into the screen than you already do, which was already presumably your intent when you switched to the font. Wouldn't that be the logical end-limit here? After all, most tools still standardize around 80 characters, most terminals on GUI machines start up for the first time with 24 rows and 80 columns. It seems like you're arguing against an unnecessary standard.
Hell, wouldn't the proper solution here be to add a flag or a config file to the analyzer to alter the defaults, rather than. This is already a solved problem for code analyzers in general, most C linters (including clint) support these flags.
I'm actually not arguing to change the default, I'm arguing that the team should have a conversation and decide on whether the default is reasonable for them. I'm not using a narrow width font because I want to pack more information on the screen, in fact I'm using it because it's more readable, at any size (small or large.)
I actually hope that when I have this conversation with my team, someone looks at my screen and says "hey, that is a nice font, and more readable than what I've been using."
> After all, most tools still standardize around 80 characters
I use standard Linux tools for development, and none of the tools themselves have any column standard. Probably text-only emails are the only thing that have a "standard" of 80 columns.
> most terminals on GUI machines start up for the first time with 24 rows and 80 columns
This doesn't really mean anything. I don't think there's anybody who leaves the terminal as it is, as even on a modest 1080, that'd be one quarter of the screen area.
I get your point, but i think the main reason for using 80 character line length nowadays is that its more readable. Books use often line lenght of about 60 characters for this reason.
That's fine, when it is more readable... but there is a convention in Ruby of making your classes and method names as descriptively as possible, not even ruling out the possibility that they might be very nearly full sentences.
I am in strong agreement that there should be a character limit, and I'm even convinced that my 180 character wide terminal is longer than what would be an appropriate limit. But 80 characters is less than half of that, and so I'm not convinced that honoring a default 80 character limit is going to make anything more readable, more likely that it will just result in me turning up my font size so there is not so much unused space on my screen.
I think it's also true that most people use a larger than 80 character wide terminal today.
I guess the point is, without getting hung up on this knob in particular, that fewer knobs is pretty much always better; at least that was the central theme of the issue where I got the idea that Rufo maintainer team has this outlook: https://github.com/ruby-formatter/rufo/issues/2
On that knob -- I prefer 80 characters today because it allows me to place two panes of code side-by-side without wrapping on one monitor. Sometimes I throw in a REPL pane as well as or instead of the second pane.
But I also have come to like prettier's approach. At least, I did last time I used it a year or two back. Almost no configuration, no bikeshedding, it just reformats your js code and doesn't sweat the rest. It's not having every style exactly how I like it, but it's much nicer than the eslint/jshint/etc hell I used to configure. Of course to some extent these tools solve some different problems but I didn't really feel much of a need to keep eslint around once prettier started enforcing its standards.
This! I prefer 80 characters so I can have two panes of code side by side or a REPL next to my code. It is near impossible to do that on a laptop if the line length is extended to 110 without a line wrap.
Point being, everyone has very different preferences and work practices. Team standards are going to be very different from team to team but standards do help reduce cognitive overhead on wondering if line lengths or other styles need to be different.
80 character is better for us old coders who need a larger font size but still want to see two files side by side on a small laptop screen without side scrolling.
I'd love to accommodate you, but I'm still struggling to get my team of 8 to agree that we should impose any line length limit. My terminal is 180 characters wide because I have some team members that don't seem to believe in line breaks as a force of habit.
You don't even know how long these 100 line functions really are! It's abusive, bottom line.
This has been my experience too. Fortunately rubocop makes it easy to distribute alternate settings as gems. I use https://github.com/sider/meowcop as a reasonable base setting. It's more relaxed about style and makes rubocop more of a linter, which is what I want.
What are some pain points in your experience? You don't have to be super specific but I'm just curious what parts get in your way when you use it with standard config?
I'd say that in our environment we introduced Rubocop into a 4 year old Ruby project that started on Ruby 1.9 and is now on 2.5, our code has a lot of warts.
We run rubocop (including a handful of our own custom cops for enforcing US-english spelling, and some specific "remember to use a transaction here") only on changed files (using codeclimate)
That means as we gradually touch more and more of our older code, we slowly enforce the styleguide.
We don't run a lot of custom configs globally (none, I think) and disable selective overzealous cops on specific lines, or blocks.
Some notable annoyances are `def Something()` which is named this way to model it after the coercions in Kernel, which rubocop complains about because of the pascal casing, and a couple of cases of too-long-lines in long, long, long doubles/mocks in rspec specs, which is a separate problem of its own.
I'm fairly new to Ruby after having many years of Python and JS experience. One of the most annoying things I find with Rubocop is it asks me to break every 5-10 lines or so into a separate method by default. I mean, Ruby is not a particularly verbose language, so I don't understand why a linter will encourage people to break non-reusable details that are only a couple of lines long into separate methods. I mean, if I have to jump around half a dozen different methods and classes every time I look at a method, does it really help comprehension at all? Do Rubyist really write code like this as a second nature?
Personally, I mostly set the length to 15 lines because too often 10 lines maximum just doesn't work in real life codebases
> Do Rubyist really write code like this as a second nature?
In my opinion yes, only the "old timers" that came from some other technologies write these annoyingly long methods (with many temp variables) and then they "wine" about rubocop.
> I mean, if I have to jump around half a dozen different methods and classes every time I look at a method, does it really help comprehension at all?
If you have to jump around, then the method names were chosen badly.
I would ask if you're doing Ruby, or object oriented design? Because the first rule of SOLID is Single-Responsibility, and there is this great concept frequently repeated in the OO design circles of Ruby conference talks, "I just want to send a method to an object." I can't say for sure that your method longer than 5 lines is breaking this rule, but if I was a betting man, I'd bet it's breaking one of those rules.
Check out sandi-meter, something much simpler than Rubocop, but also includes this rule about 5 lines method length limit. Maybe you know Sandi Metz, and if you do, maybe you haven't heard of the "Sandi Metz Rules" from POODR; rule number two is "more than 5 lines" – my favorite rule is "controllers with more than one instance variable."
The great thing about this tool as opposed to RuboCop is that one thing should be really clear when you start using it on an existing code project... the way to interpret the big red spot on your chart is NOT that you should go out and change those things immediately to conform to the new rules.
I understand why you want one instance variable per controller, as the job of a controller is really straightforward, if it only exposes a RESTful interface to a single class of objects, but the more specialized features and bolt-ons it accumulates, the less straightforward it will be to understand and refactor the controller code. But when you're taking an existing controller and adding a new feature to it, the right abstraction to use is probably not obvious until you've spent some time with the idea of the feature, maybe tried out a few different implementations.
For a lot of this stuff, when it clicks, you get it, but before then it seems like these rules have no purpose and it doesn't benefit you to follow them blindly. It pays to know when a rule is important, and when you can safely ignore it.
So, what I would say in response to your question is that simply breaking the method in two is not necessarily the refactor that is suggested by the rules of OO design. You should go back to the principles and try to figure out why that method is longer than 5 lines, and what else about the class has resulted in methods that are so long; is it related to having broken one of the more fundamental rules of design, and is it likely to present an obstacle to later change? (Or is this method never likely to change, and you should just ignore it because... it's fine! This is often the answer.)
Maybe you wrote this method to honor some complicated scheme of ideas, that are really separate ideas, and maybe they should be extracted into separate classes so that it's easier to validate changes to the ideas when it's time to change those business rules. (Or, maybe none of that is true, and they should really be kept in one place because how else are you going to understand all the rules and interactions between them, than by having them together) – Chances are good, though, that the code has broken one of the more fundamental rules, like Open/Closed or Dependency Inversion, and that there is a way to make the method simpler without compromising readability. Maybe there are some heavy calculations that are done inside of the method, and it would be better for DRY to extract them into another method that has a descriptive name, and simply lives nearby.
POODR is a great read I'm told; Refactoring is also an important reference work, and if it's too dry for direct consumption, there are great adaptations that will help get you up to speed on code smells and remediation strategies like https://refactoring.guru
I appreciate this detailed response, but I'm afraid if it takes an essay to respond to a simple question of "why break out if more than 5 lines", and the reader with 15 years of programming experience who's well-versed in half a dozen general purpose prog langs still haven't got a clue after reading it, it suggests to me that this is cargo-cult programming.
Ruby is not the first language that has OOPish constructs, but no one else tells devs they are probably writing bad code if they need more than 5 lines of code in a method. I mean, what's wrong with a controller methods that just splits into 2 branches based on the existence of a param, and creates a model and save it to the DB? The entire method will consist of around 20 lines of code. There's no instance variable, no cache and no error handling whatsoever. Do Rubyist get a headache after reading 5?
I'm all for OOP but there seems to be quite some amount of OOP BS around, especially in the Ruby community.
Is it a method that's longer than 5 lines, or is it a method that is longer than 50? Because one of these things I could see being easily explained away without haranguing, but the other one is what I deal with on my team on a regular basis.
The point I was trying to make isn't that your methods shouldn't be longer than 5 lines, it's that they should be single-responsibility and descriptively named, like the well-designed classes they inhabit.
The 50+ line method which mixes query and command behaviors indiscriminately is the problem. The 5 line method rule is simply one possible distance to the goalposts (and you are free to move the goalpost, no bullshit intended!)
The point is not that methods should be 5 lines or less, full stop. The point is that people who are in the habit of writing methods that are above (threshold value X) ... and leave it this way, boilerplate and all, then spam the same 50 lines everywhere, except on Tuesday when it looks like this other variant... are perhaps contributing to some kind of a trouble state that should trigger at least a second glance whenever your process has you get around to doing code reviews. It's likely one of the same reasons you or your team has reached for this tool to begin with.
If the effect of implementing the tool into your process is that people are still squeezing command and query ideas that don't belong together into the same method, now in fewer lines than ever before, then it's not having all of the desired effect and it sounds like there is still a conversation that needs to happen about what is a good and bad design for a method.
I'm not saying that your personal boilerplate is wrong, (but I am suggesting it might be, based on a metric that is easy to compute.)
It's a tool that you use to identify symptoms of a problem. The symptoms are not the problem, and they may not even be indicative of any real problem. Sometimes you get a sniffle.
> The point is not that methods should be 5 lines or less, full stop.
But that's what a linter does! It just blindly says that shit is wrong. Linters should only emit warnings that people definitely should fix otherwise people stop paying attention and all the useful checks become just noise.
I'm not saying that this rule is the most beautiful rule, or that you're a bad person if you write methods that are longer than 5 lines and don't get permission from a senior architect first. That's something dysfunctional teams might do.
Look at `--auto-gen-config` because you can totally still use rubocop on codebases that have loads of pre-existing violations in them without fanfare. Then each new violation needs a second look, and an addition in this file. And if the rule is too restrictive, you can change the default away from 5 lines to some bigger number. The principle I hope (Rubocop hopes) you will accept is that short methods are easier to understand than long methods, so shorter methods should be preferred, at least absent other pressures... that's all. The point I guess is to establish a standard, and then iterate on it.
I don't want to start name calling, but Sandi does this talk where she starts out "who knows code smells" and everyone puts their hand up, then she says "who can name 5 code smells" and all the hands go down. Watching this talk was eye opener for me.
Can you write a program that is well organized and doesn't have methods longer than 5 lines? I don't know if I can. Does that mean the metric is bad and should be thrown away without looking back? I'm not ready to go that far, I want to learn more and know how to make this possible, because Sandi and many others with 30+ years experience in OOP have taken time out from their busy day to suggest that it will result in more maintainable code for my team.
There is a big difference between cargo culting and listening to learned experience projected outwardly.
I will say also that I have >15 years of experience programming in different languages and I've only felt a need to reach for these design concepts in the last 2.
Please don't feel like I'm talking down to you. We are the same. I don't even use these tools, and my methods are very often too long.
Ruby is one of the few languages optimized for developer happiness. It consciously makes tradeoffs in favor of that primary purpose. It is natural to expect a focus on the developer experience among its users, such as ensuring code is highly readable (as embodied in the short method reasoning). I do think some developers become overzealous and do sometimes overstate Ruby's features.
After spending some time to think about your reply, and watching an OO talk or two, I have a clearer way to state why your statement is unlikely to be true in context. I am not an OO "seer" or visionary, I don't mean to say you are broadly wrong, but in the framework of OOD and SOLID, I think that 100+ line method is almost definitely not just doing a single thing.
The Single Responsibility Principle is said to cover all the reasons why a class might need to change. There should be only one reason why a class changes – its single responsibility is that reason. That's for an entire class. Your method lives in the class, so get out your class and read down, method by method and line by line.
Ask yourself periodically while you do this, "can this line of code ever change, in some future state of development?" and "what are the reasons it might change?" – this is not a value judgement, I am just saying that I think by the time you get to the bottom of the method, you'll find the list has decidedly more than one distinct entry in it. (Maybe you don't, and in that case you could have a thing or two to tell me about how you made it that way... please be sure I'm not claiming superiority, especially given that I haven't actually read your code!)
Object Oriented Design is all about managing software change, and making change easy. Your 100+ line method is perhaps not easy to change (and validate.) Maybe it is only called by one other line of code anywhere, and my concerns are ill-founded! It does the same thing every time, and it's just one thing, even though it takes a while and perhaps has many un-named steps.
But if you can think of more than one reason for that method and the class it lives in to need to be changed, then the principles of OOD may say you have run afoul of the S in SOLID, and should maybe reconsider.
One of the things I think we all have a hard time coming to grips with is this maybe reconsider – just because you have identified a code smell, doesn't mean you should fix it! There might be (definitely is) more than one way to fix it, there's also a good chance it might never need fixing.
Your use of the word "every" makes me believe that I have not made my point clearly. I will try to restate it in less than 5 lines so that it can be understood better. (Zing!)
I'm not saying that your code is wrong, (but I am suggesting it might be, based on a metric that is easy to compute.)
It's a tool that you use to identify symptoms of a problem. The symptoms are not the problem.
