All variables SHOULD be named so they explicitly display there aesthetic or purpose back to the developer without any confusion

[BenjaminRCooper]

Explicitly stating what a variable contains is a lot more memorable to a fellow maintainer, than using a long generic string which is forgetful, and has you reaching for your variables file, every time you require to use it.

Example:

// ================
// Font Family Variables
// ================

$font-family-sans-serif: 'sans-serif';
$font-family-helvetica-neue: Helvectica-Neue, 'sans-serif';

// ================
// Color Variables
// ================

$color-blue-dark: #0000FF;
$color-blue-light: '#00FFFF';

[iamrossgrant]

• 1

[timgale]

Hey man

I completely agree with this approach to naming variables.

Just one suggestion that relates nicely to the example above. Would it not be more practical to reuse the initial $sans-serif variable when declaring the second? E.g.

$font-family-sans-serif: 'sans-serif';
$font-family-helvetica-neue: Helvectica-Neue, $font-family-sans-serif;

By extending the base variable in subsequent definitions, we are reinforcing a DRY approach to our presentation standards.

In many scenarios this will not always be an option, but it may be beneficial to move towards this wherever possible.

Tim

[lewismorris]

+1

[BenjaminRCooper]

+1

[markgoodyear]

Hey guys,

Just want to quickly revisit this one. Regarding colour naming conventions, rather than referencing the actual colour, how about something along the lines of:

$color-primary:      #0000FF;  // comment to explain colour eg:
$color-secondary:    #00FFFF;  // blue-light

The reason for this is on a project (using the primary/secondary method), the colours needed to be changed, so just changed them in the vars file, saving going through and changing all the variables used elsewhere too. Could be along the lines of:

// Brand colors
$brand-color-primary:     ######;  // blue
$brand-color-secondary:   ######;  // green
$brand-color-tertiary:    ######;  // yellow

// Brand fonts
$brand-font-primary:      'Helvetica Neue', 'sans-serif';
$brand-font-secondary:    'Georgia', 'sans-serif';

// Misc colors
$color-blue-dark:         #0000FF;
$color-blue-light:        #00FFFF;

I've found something like the above makes it far easier to swap out colours/fonts, and generally works across different projects.

What are your thoughts?

[ampersarnie]

@markgoodyear I usually go with the original as more often than not, when the design comes to development stage, it has already gone through the necessary changes. But I can see the benefits of what you're suggesting, especially if it's for a design that is expected to have colour alterations.

[BenjaminRCooper]

Mark,

This was the original approach, but when the codebase becomes larger, it gets a lot harder to remember what certain variables reference in terms of their value.

Maintainability wise, our solution is not a brilliant solution and I totally agree with the above, but we have agreed to sacrifice maintainability for productivity.

We can run with it for now, and then see how it pans out.

Ben

[jonspark]

Would a combination work? Or is that confusing things further? Thinking it might be a bit more flexible and maintainable.

// ================
// Font Family Variables
// ================
$font-family-sans-serif: 'sans-serif';
$font-family-helvetica-neue: Helvectica-Neue, 'sans-serif';

// ================
// Color Variables
// ================
$color-blue-dark: #0000FF;
$color-blue-light: '#00FFFF';

// ================
// Brand colors
// ================
$brand-color-primary:     $color-blue-dark;
$brand-color-secondary:   $color-blue-light;
$brand-color-tertiary:    $some-other-var;

// ================
// Brand fonts
// ================
$brand-font-primary:      $font-family-sans-serif;
$brand-font-secondary:    $font-family-helvetica-neue;

It ought to work for brand elements at the very least. It's possible that it's just down to a inappropriate var name, but $font-family-helvetica-neue is akin to the old classname of 'red' and then having the colour set to blue.

[BenjaminRCooper]

Love it mate.

Ben

[BenjaminRCooper]

+1

[markgoodyear]

@jonspark That's the reason why I try use generic names. Is using $color-red any different than having a class called .red?

I'm +1 for what @jonspark has. Stuff like link colours/hover, buttons etc. are likely going to be a brand colour, so tying that to the brand variable makes sense. Then when it does change (rebrand or for a new project), you're only updating the vars file.

[BenjaminRCooper]

How often are colours and font-families going to change? If they do change, they usually change ever so slightly so using something like $color-red is usually still relevant.

Changing variable references within files is not a huge job and the reasoning behind using a naming convention which is relevant to the aesthetic of an element was made as we thought it was more useful to the team to have understandable naming compared to something that is vague.

I am completely for using aliases if you require it, but the original thought was it is easier to remember the current naming convention and that route was chosen.

Ben