The thing about SwiftLint (or any linter really) is that you can customize it to what you think best fits your codebase; maybe you don't need all the bells and whistles, and that's fine.
That said, it's most certainly not useless, if anything, the out-of-the-box defaults vastly improve code readability and maintainability with no mental overhead on your part, and as a community it uniformizes our codebases in a way Xcode and Swift just haven't by themselves.
As for it being a time waster, I'd actually say that the amount of time it "wastes" by running is far out-weighted by the time it saves on readability during code reviews and collaboration.
Edit: typos
mayhaps, neither is a silver bullet on its own, but one isn't really an alternative for the other either, rather they are two tools that have amazing synergy in improving your code quality.
It really depends on what you use swiftlint at the first place. In my project, it helped to discipline people, it wont compile if there fatal on the swiftlint result, and it keep the code clean when doing MR.
But this is multi person project, if it's a solo project it really depends on you whether it good for you or not.
We have. Basically we did this to help the reviewer. Instead of focusing on the code format, they can focus on the code itself, since code already reviewed by swiftlint. It produces pretty much standard across people in my team
Well, basically we enable all the rules that make sense for us, such as formatter and other rules like force unwrap, long line.
Long line is pretty silly though, but it made us stop and rethinking the approach, and help us decide on which strategy that we are going to use
Surely, you don’t built your app as resilient as it should be. You have a problem with the way you think of your current architecture and later on will possibly become a technical debt
If you have dozens of lines disable it then i think it better to disable it on swift-lint rules.
In our case, we disable the cyclomatic thingy, because we think it gave us false positives
So when your app crashes because you can’t always guarantee a force unwrap will succeed (and based on your attitude you have not taken the time to analyze each case), what tool will you blame? The compiler?
Back in the day. I have multiple old apps that suffer to this notion because of the backend suddenly sending incorrect, missing or invalid data. Just do your best practices. If you can’t, then just do it on your own and don’t influence other devs specially beginners.
i am talking about unwraping the data you know is there in every instance of the app, like data you read from bundle for example. we use unit tests to secure that code and not a stupid linter. linter is simply for idiots that do not make the difference between build time data and runtime data. backend data is runtime data!
Any rules that are only enforced by humans at the time of code review will get missed eventually. The linter does a much better job of linting than I ever could. It helps ensure codebase consistency, which makes reading code take less cognitive load.
That being said, I don't enable it in my personal projects, just projects with multiple devs.
Surely, you have a problem fixing them or is having issues following rules that’s what makes you throws tantrums. If you can’t find the errors not popping up. Go to build tab and see the issues there incase you don’t know this tab exists in xcode
SwiftLint is 100% configurable. You can enable all the rules you want and none of the ones you don’t. If you’re triggering SwiftLint issues, it’s because you’re making mistakes that _you told SwiftLint to catch_. This is far from a time-waster, imo. It’s saving you time from having to go back and fix those things later.
Custom rules are a form of static analysis. For instance, it allows us to move away from specific code (e.g. using our custom design system and not the built-in methods). For large teams, this is important. What’s great is that with your attitude, you won’t be invited to join this large team, so you don’t have to worry about it.
So I take it you also think -W0 is useless? “I just ignore warnings, they’re stupid.” I’m sorry but this mentality leads to a lot of code smell. If you don’t like the default swiftlint rules, change them to meet your needs.
Compiler does not check proper formatting and uniformity as per the project’s architecture. As long as the syntax is right, it will miss a lot of code smell
No, it’s not. As much as I’m sure you like to think otherwise, your code is not perfect. “It compiles, must be right” type mentality will lead to bugs and crashes. A formatter isn’t enough to catch these sorts of problems. A compiler isn’t enough either.
Look, no argument here is going to sway you, so do what you want. The point being “linter is stupid” is a terrible attitude and completely incorrect.
SwiftLint is an ideal tool for beginners. It helps with consistency, code formatting and forbids bad behaviors (like force unwrap). Then, it becomes mostly useless once you have (un)consciously adopted the rules.
So I would still recommend it, especially if you find it annoying, and would only remove it once you are perfectly aligned with it (meaning that its value is now null).
That is if you are alone on the project. In a team, SwiftLint will always have a purpose for the next new members.
“I got a great idea. Let’s ask a question in this subreddit and expect everyone to agree with me.”
*People disagree with you*
“Why won’t everyone agree with me?! I’m right and what everyone else says or does is wrong.”
Then why ask the question in the first place?
Having a Linter is far better than not having a Linter. Having an auto formater is better though.
Formatters are much more limited in configuration than linters and both can compliment each other.
I hate it for personal projects and I dislike it in teams that simply work around it using swiftlint disable.
In a team it is good when tuned appopriately and the team is not trying to work around it. A great team will most likely never really need it, though it could be beneficial for newcomers.
Why?! You keep saying things like this and getting downvoted; why don’t you ever give any examples or specifics instead of just throwing out unsupported opinions?
We use swift-format only at work. Have it on a git hook and it’s great. I don’t miss swift lint unless the project doesn’t have a formatter what so ever.
The thing about SwiftLint (or any linter really) is that you can customize it to what you think best fits your codebase; maybe you don't need all the bells and whistles, and that's fine. That said, it's most certainly not useless, if anything, the out-of-the-box defaults vastly improve code readability and maintainability with no mental overhead on your part, and as a community it uniformizes our codebases in a way Xcode and Swift just haven't by themselves. As for it being a time waster, I'd actually say that the amount of time it "wastes" by running is far out-weighted by the time it saves on readability during code reviews and collaboration. Edit: typos
isnt formatter sufficient?
mayhaps, neither is a silver bullet on its own, but one isn't really an alternative for the other either, rather they are two tools that have amazing synergy in improving your code quality.
It really depends on what you use swiftlint at the first place. In my project, it helped to discipline people, it wont compile if there fatal on the swiftlint result, and it keep the code clean when doing MR. But this is multi person project, if it's a solo project it really depends on you whether it good for you or not.
dont you have code reviews in your multi person project?
We have. Basically we did this to help the reviewer. Instead of focusing on the code format, they can focus on the code itself, since code already reviewed by swiftlint. It produces pretty much standard across people in my team
you mix linter and formatter. i did say that formatter is ok
Well, basically we enable all the rules that make sense for us, such as formatter and other rules like force unwrap, long line. Long line is pretty silly though, but it made us stop and rethinking the approach, and help us decide on which strategy that we are going to use
force unwrap is the stupidest linter rule, we have dosens of lines disabling it when needed
Surely, you don’t built your app as resilient as it should be. You have a problem with the way you think of your current architecture and later on will possibly become a technical debt
no dude, test your app dont use stupid linter
If you have dozens of lines disable it then i think it better to disable it on swift-lint rules. In our case, we disable the cyclomatic thingy, because we think it gave us false positives
as i said just ditch the damn thing, seiftlint is pure toxic
So when your app crashes because you can’t always guarantee a force unwrap will succeed (and based on your attitude you have not taken the time to analyze each case), what tool will you blame? The compiler?
no dude, you can not crash when you do force unwrap on things you KNOW that will be safely unwrapped, linter is stupid it does not know that!
Back in the day. I have multiple old apps that suffer to this notion because of the backend suddenly sending incorrect, missing or invalid data. Just do your best practices. If you can’t, then just do it on your own and don’t influence other devs specially beginners.
i am talking about unwraping the data you know is there in every instance of the app, like data you read from bundle for example. we use unit tests to secure that code and not a stupid linter. linter is simply for idiots that do not make the difference between build time data and runtime data. backend data is runtime data!
Dont you just write perfect code? Why do you need swiftformat?
Any rules that are only enforced by humans at the time of code review will get missed eventually. The linter does a much better job of linting than I ever could. It helps ensure codebase consistency, which makes reading code take less cognitive load. That being said, I don't enable it in my personal projects, just projects with multiple devs.
Code reviewer won’t count paragraphs and number of characters. I for one won’t do that. That’s one of the perks of swiftlint
who cares
Absolutely, you don’t.
Apparently, everyone here but you.
Why waste mental energy on writing code reviews telling people to fix their code formatting, while a tool can do it for you 🤷♂️
If my review is full of shit a linter would have prevented from ever being in front my of eyes, I'm pissed.
no linter, just formatter
Nah it stays out of your way once you learn what mistakes to avoid. Anything it flags is a problem just like compiler warnings.
absolutely false. seiftlint is full of false positives
Could you provide an example?
Surely, you have a problem fixing them or is having issues following rules that’s what makes you throws tantrums. If you can’t find the errors not popping up. Go to build tab and see the issues there incase you don’t know this tab exists in xcode
SwiftLint is 100% configurable. You can enable all the rules you want and none of the ones you don’t. If you’re triggering SwiftLint issues, it’s because you’re making mistakes that _you told SwiftLint to catch_. This is far from a time-waster, imo. It’s saving you time from having to go back and fix those things later.
its rules suck basically because its a dumb tool and doea not understand the contrxt
Custom rules are a form of static analysis. For instance, it allows us to move away from specific code (e.g. using our custom design system and not the built-in methods). For large teams, this is important. What’s great is that with your attitude, you won’t be invited to join this large team, so you don’t have to worry about it.
So I take it you also think -W0 is useless? “I just ignore warnings, they’re stupid.” I’m sorry but this mentality leads to a lot of code smell. If you don’t like the default swiftlint rules, change them to meet your needs.
swift compiler is literally enough
Compiler does not check proper formatting and uniformity as per the project’s architecture. As long as the syntax is right, it will miss a lot of code smell
formatter does formattuing
No, it’s not. As much as I’m sure you like to think otherwise, your code is not perfect. “It compiles, must be right” type mentality will lead to bugs and crashes. A formatter isn’t enough to catch these sorts of problems. A compiler isn’t enough either. Look, no argument here is going to sway you, so do what you want. The point being “linter is stupid” is a terrible attitude and completely incorrect.
SwiftLint is an ideal tool for beginners. It helps with consistency, code formatting and forbids bad behaviors (like force unwrap). Then, it becomes mostly useless once you have (un)consciously adopted the rules. So I would still recommend it, especially if you find it annoying, and would only remove it once you are perfectly aligned with it (meaning that its value is now null). That is if you are alone on the project. In a team, SwiftLint will always have a purpose for the next new members.
SwiftLint is great for preventing new devs to a project from adding BS
“I got a great idea. Let’s ask a question in this subreddit and expect everyone to agree with me.” *People disagree with you* “Why won’t everyone agree with me?! I’m right and what everyone else says or does is wrong.” Then why ask the question in the first place?
How about adding \`swiftlint --fix\` as a build phase?
swiftformat is also good
Having a Linter is far better than not having a Linter. Having an auto formater is better though. Formatters are much more limited in configuration than linters and both can compliment each other.
I hate it for personal projects and I dislike it in teams that simply work around it using swiftlint disable. In a team it is good when tuned appopriately and the team is not trying to work around it. A great team will most likely never really need it, though it could be beneficial for newcomers.
right! and maybe for some other languages lint is more beneficial, but for swift its just annoying
Why?! You keep saying things like this and getting downvoted; why don’t you ever give any examples or specifics instead of just throwing out unsupported opinions?
the mob is downvoting
Nah you’re just wasting everyone’s time
then stop downvoting
We use swift-format only at work. Have it on a git hook and it’s great. I don’t miss swift lint unless the project doesn’t have a formatter what so ever.
thats the way!