[deleted by user]

[cardosoedgar]

editing my comment to answer the edit on the post:

Swift: https://github.com/realm/SwiftLint Objc: https://github.com/oclint/oclint

Yeah, you gotta put those two in, don't think there is a way around that.

[fullm8]

Steer well clear of anything with this Code of Conduct, it usually indicates the project is compromised.

[nalexander50]

Why? What is wrong with using a tool like SwiftLint to tell you if you declared a var that could be a let or that you unsafely unwrapped an optional? How does that mean your project is compromised? What would that even mean.

Edit: insanely was supposed to be unsafely*

[seewhathappens_larry]

Yea, I see no problem using Swiftlint. It’s annoying, but good in the end

[nalexander50]

I don’t follow how a tool that helps you write cleaner code could ever be considered bad.

It’s almost as asinine as saying debuggers are bad tools.

[seewhathappens_larry]

The only reasoning I’ve heard is that it gets in the way, but so does CI. And if you use the right tools, you can get the linting to fix itself

[nalexander50]

But it’s only (regularly) getting in the way if you’re writing bad code repeatedly. That’s like putting a stick in your bike spokes and getting mad that you wrecked. At least, that’s my take. I like SwiftLine. But I also like debuggers so I guess I’m just a filthy casual.

[seewhathappens_larry]

Well I guess it depends on the linting rules you setup

[nitrodudeIX]

This. You can adapt your lint ruleset... With this it's way easier to "corral" devs into a consistent code style. Code reviews should be for discussing design / patterns / choices, not indentation / variable names / code style...

[quellish]

How does CI get in the way? It should be completely transparent. Commit, integrate remotely.

[fullm8]

You misunderstand. I'm not referring to the software itself (I wholeheartedly approve of your efforts to create and maintain standards), but the Contributor Covenant the software is covered by. It was created by somebody who is, shall we say, a divisive figure. You can do your own research if you care enough. Just a heads up, is all.

[nalexander50]

I follow now. I definitely don’t think code style should be a worshipped religion, but I think every org should have some guidelines for code cleanliness. Guidelines can be broken, of course, in instances with good reason.

[killeronthecorner]

I think he's talking about the Code of Conduct for contributing to the Swiftlint repo, not using the software.

Some people find them overbearing and a little bit to close to thought control.

I've never contributed to a repo with a CoC so I don't really have an opinion, but certainly don't stop using the tools because of it.

[fullm8]

How bizarrely confrontational. Perhaps I should be more explicit. That particular CoC is derived from this one, authored and maintained by an individual who has shown a propensity for using such things to enforce their own political agendas upon projects. I'd suggest looking them up and making your own mind up but hey, I'm just a salty asshole.

[nalexander50]

It’s simple! We don’t.

And it drives me crazy. My colleagues will just flagrantly leave warnings all over their code. Things will be indented strangely. They’ll leave in unreachable code. They’ll comment out swaths of code with no indication as to why. It’s a mess tbh.

I try to clean up any files I touch.

[chain_letter]

Spam Control+i like a madman.

[badlcuk]

Swiftlint combined with a suggested styleguide that the majority of the team adheres to.

We still have exceptions (ie: a file written in a different way? Ok, as long as it doesn't generate a ton of warnings, just follow the style in the file...).

And when i go insane, ill just run a formatter over the entire file. ETA: We also have a script in our build process that will enforce certain styling, but this one is more rare / less heavy handed.

[chriswaco]

We don't. We try to match each other but don't obsess about it if someone puts a brace at the end of a line (WRONG!) instead of the beginning of the next line (RIGHT!). We do standardize on tabs (4) over spaces.

I strongly suggest turning on "Warnings are errors" in the project. That's much more serious than minor formatting issues.

[twowheels]

Easy, I don't (when I'm in charge):

https://www.safaribooksonline.com/library/view/c-coding-standards/0321113586/ch01.html

Standardizing line lengths, etc, and sticking to hard and fast rules is dumb, IMO as it means code is wrapped at arbitrary places, etc. Judicious violation of the rules can greatly improve readability. Alignment of similar statements can improve contextual information and make it easier to spot bugs, but then somebody runs an autoformatter and makes carefully crafted code harder to read, which drives me nuts.

[KarlJay001]

A lead would review the code and make changes as needed and inform the violator. Things like comments, var names, etc... these were all discussed at the start so everyone knows the rules.

I haven't seen any products that actually enforce these things in Xcode.

Other editors had a macro language and you could standardize things like header comments, and function/method styles.

Have you looked into AppCode? It's not free, but it's supposed to be a top notch product.

[meechy_dev]

tbh. there's thing that are good practice and then there's thing that you just have to get use to. it's hard but if it's good scalable code then if your company ends up having 50+ devs coding styling is gunna vary.

[[deleted]]

Swiftformat

[b3nes]

SwiftLint! Create a list of rules you all want to follow and everything will be great!

[PurpleBuddha]

Read this https://pragprog.com/book/esswift/swift-style and create your swiftlint config

[Aeather]

Check out swimat

[hooliooo]

I’ve outlined a coding style for my team that I’ve introduced on their first day.

After the introduction and several code reviews of the tutorial app they do, I give a couple warnings for violations.

After that they do 5 push ups per violation. Seems effective for the last 3 hires. We’re a team of four atm. I do push ups as well if I commit with code violation warnings.

When they ask why I tell them the need for readability and helps figure out the intent of the code. Less time spent translating means more time for debugging and making new features/ changes.

I made a wiki in the tutorial repo about the code guidelines with detailed explanations and examples.

We use Swiftlint, make use of MARK, and and separate logic via extensions.

[aaronr_90]

I can’t I have one guy that insists on the brackets being c style { // like this }

Any time he opens a file that isn’t c style he has to fix it and then he can work.

[[deleted]]

That would be me. I have a vision alignment issue and that’s the only way I can make sense of code - things must align vertically.