This is purely an inquiry on how others handle this kind of thing. When it comes to constants, lets say providing 20 points of padding. I'm not a fan of seeing alot of the number 20 scattered around in the code, whether using it for padding or numbers in a for loop.

I've been doing something like the following in my code:

enum Constants {
  static let i20: Int = 20
}

Then in code i would use it like:

.padding(Constants.i20)

What are your ways of doing this kind of thing or do you do anything like it. I had a teacher in school college teach us that. Anyways, just currious if theres a better way or if this is a good way to handle constants.

Thanks,

Taz

I tend to make a constant that is local to whatever View it's used in rather than a global enum.

@roosterboy

Thanks for the reply, I appreciate that. Thats a good way to do that.

Mark applies nice logic to organizing code:

When it comes to constants, lets say providing 20 points of padding. I'm not a fan of seeing alot of the number 20 scattered around in the code, whether using it for padding or numbers in a for loop.

If you've watched some of the CS193p lectures, that Paul calls these "magic numbers." I've seen it called this in other places too.

And you're right! Having those number scattered throughout your code makes it hard to make adjustments and tweak your layouts. But don't stop at just padding! You can use these for color themes, font names, font sizes, etc. Any tweaks you might make to how something looks is a candidate for your Constants enum.

Developers vs UX Designers

Here's another thing to consider. At some point, you may be writing an application but have no say in how the interface looks. Someone else will be calling the shots on field heights, font size, spacing between elements, button sizes, colors, logoSize, etc.

You'll get a specification sheet with all these magic numbers and specs. And you can be sure just as soon as you deliver a prototype, there will be major changes to that spec sheet! So, instead of variables named i20 (for 20 point integer?) you might consider naming your variables according to their purpose in the specification sheet. Plus, in the world of agile development and test driven methods, having a handy list of element constants is a good way to confirm your adherence to published user stories.

 static let logoSizeSmall            = 120  
 static let logoSizeLarge            = 320
 static let spacingAfterHeader       = 20
 static let spacingBetweenFormFields = 12
 static let saveButtonHeight         = 35

This may triple the number of static constants you have. But it may make it easier for you to adjust individual elements for the overall look and feel of your application.

// instead of 
    .padding(Constants.i20)
// you'll use
    .padding(FormConstants.spacingBetweenFormFields)
    .frame( width: LogoConstants.logoSizeSmall, height: LogoConstants.logoSizeSmall) // Different collection

Added bonus. If you're coding a view and find you don't have a defined specification for some element (Slider?), you'll know immediately and can notify your design team.

As always, your mileage may vary!

@obelix,

Thanks for the reply. I had a buddy mention this same thing to me. Appreciate the advice. I have had many of those moments where design changes rapidly during development. I always felt like my Constants enum was growing out of control, just never really considered have multiple enums for various UI/UX stuff.

I do see how that would make more sense. As my buddy suggested and now you suggested having meaningful names makes it much more clear what the constant is for.

Thanks, Taz