Skip to content

[FIX] update the guidelines for enumeration switch cases #26

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

[FIX] update the guidelines for enumeration switch cases #26

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
61 changes: 61 additions & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -133,6 +133,67 @@ enum Shape {
}
```

## Switch Statements
1. Enum cases with an associated value should have a appropriate label as opposed to just types
Copy link
Contributor

@mokagio mokagio Aug 23, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sentence needs a . at the end 😉 .

Also, what is the rationale for this recommendation? It should be added as well.


***Preferred:***

```swift
enum Trade {
Copy link

@pablocaif pablocaif Aug 21, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

case buy(stock: String, amount: Int)
case sell(stock: String, amount: Int)
}
```

***Not Preferred:***

```swift
enum Trade {
case buy(String, Int)
case sell(String, Int)
}
```


2. When using a switch statement that has a finite set of possibilities, do not include a _default_ case. Instead, place unused cases at the bottom and use the break keyword to prevent execution.

```swift
enum UserState {
case loggedIn
case loggedOut
case openCatalogue
case onboarding
}
```

***Preferred:***

```swift
func handleUser(with state: UserState) {
Copy link

@pablocaif pablocaif Aug 21, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not 100% agreed for this to be a guideline. I think it depends on the enum specially if the other options are completely irrelevant to what the switch is trying to address. Another example would be you have an error enum with multiple errors that and you can only act on a handful it becomes boilerplate to enumerate all of them just to follow a rule. For example something that I'm working for a personal project can throw this error https://developer.apple.com/documentation/networkextension/nehotspotconfigurationerror
Of course there are different opinions and as usual there is a balance to achieve as well as preferences are involved so if the rest of the team is ok with this I'll adhere.
Cases like

enum LoginResult {
 case loading
 case success
 case error
}

Make complete sense to have no default statement

Copy link

@pablocaif pablocaif Aug 22, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Our own NetworkServiceError is another example.

Copy link
Contributor

@mokagio mokagio Aug 23, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps this recommendation could be relaxed a bit?

There is a lot of value in not using the default case, but there are as @pablocaif suggests, instances in which it would be too cumbersome to do.

switch state:
case .loggedIn:
showMainUI()
case .onboarding:
showOnboardingFlow()
case .openCatalogue, .loggedOut:
showVisitorUI()
}
```

***Not preferred:***

```swift
func handleUser(with state: UserState) {
switch state:
case .loggedIn:
showMainUI()
case .onboarding:
showOnboardingFlow()
case default:
showVisitorUI()
}
```

### Prose

When referring to functions in prose (documentation, code comments, code reviews) include the required parameter names from the caller's perspective or `_` for unnamed parameters. Examples:
Expand Down