Software Licences

Software licenses are confusing. I thought making a summary would require some useful research and would be a great way to learn more! Also, I was inspired by this WTFPL comic about licenses.

So I sat down and started my research.

Then I broke down and cried.

Why is this shit so hard? The opensource.org site is decent, and even dares annotate pieces. However, for a summary of the popular license you’d have to construct something yourself from the bare license texts.

Anyways, I stopped crying. Grabbed both a beer and a hot cup of tea, and went in for round two. Surely Wikipedia has a good starting point? A zoomed out screenshot of the Comparison of free and open-source software licenses looks like this:

Open Source Comparison

So I started crying again.

Why I is this shit so hard? I guess it’s in part tiredom and beer (or even the tea? :O) talking, as the comparison table is actually quite informative and clean (after blinking once or twice). However, this would not help me summarize the licenses that I would consider using for a project.

In any case, I stopped crying. Poured a glass of whiskey after downing a cup of coffee. Round three.

Time to remember why I was doing this in the first place. Or perhaps not why, but more what triggered this post in the first place (besides the WTFPL comic).

The reason’s actually simple: it was the Stack Overflow license. Specifically this meta question. User  “Stefan” asks how to get permission to use a function from a SO post in GPL-licensed software. I had never thought about that: people may have to worry about all sorts of things to use entire snippets from SO posts. And heck: I am also one of “people”…

Interestingly, the solution from a code-providing point of view is simple. Posting on Stack Overflow means you release it under “cc-by-sa 3.0 with attribution required”. However, you can license it in other ways too if you so desire (and have the (copy)right to do so).  As user Pëkka puts it in this post:

Stack Overflow Copyright flowchart

So I broke down in tears again.

Why was this shit so easy for Pëkka to describe? How can I ever hope to create a text or picture about licenses equally eloquent and explanatory?

I think I can’t. So it’s probably best if I don’t write a post about licences.

CSS syntax naming conventions – REDUX

I’ve blogged about CSS naming conventions before. The Stack Exchange question I referred to then has since been closed (for understandable reasons). However, it recently also started gathering “delete” votes. Given that I don’t have enough reputation to see deleted posts on Programmers.SE, I intend to salvage up front whatever info was in that post and it’s answers here.

So, here’s the redux version of my post, along with the answers. If anything, this’ll be a good excercise in following the cc-by-sa license from Stack Overflow.


Question: what are the practical considerations for the syntax in class and id values?

Note that I’m not asking about the semantics, i.e. the actual words that are being used. There are a lot of resources on that side of naming conventions already, in fact obscuring my search for practical information on the various syntactical bits: casing, use of interpunction (specifically the - dash), specific characters to use or avoid, etc.

To sum up the reasons I’m asking this question:

  • The naming restrictions on id and class don’t naturally lead to any conventions
  • The abundance of resources on the semantic side of naming conventions obscure searches on the syntactic considerations
  • I couldn’t find any authorative source on this
  • There wasn’t any question on SE Programmers yet on this topic :)

Some of the conventions I’ve considered using:

  1. UpperCamelCase, mainly as a cross-over habit from server side coding
  2. lowerCamelCase, for consistency with JavaScript naming conventions
  3. css-style-classes, which is consistent with naming of css properties (but can be annoying when Ctrl+Shift+ArrowKey selection of text)
  4. with_under_scores, which I personally haven’t seen used much
  5. alllowercase, simple to remember but can be hard to read for longer names
  6. UPPERCASEFTW, as a great way to annoy your fellow programmers (perhaps combined with option 4 for readability)

And probably I’ve left out some important options or combinations as well. So: what considerations are there for naming conventions, and to which convention do they lead?


Amos M. Carpenter answered:

Bounty or not, to some extent the choice will always be a “matter of preference” – after all, how would you feel if the W3C recommended (or even imposed) a certain convention that you didn’t feel was right?

Having said that, though, I personally prefer the lowerCamelCase convention, and I’ll give the reasons and practical considerations I’ve used to make up my mind – I’ll do so by a process of elimination, using the numbering from your question:

(5.) justnoteasilyreadablebecauseyoudontknowwherewordsstartandend.

(6.) ASABOVEPLUSITSANNOYINGLIKESOMEONESHOUTING.

(4.) historical_incompatibility_plus_see: Mozilla Dev Documentation.

(3.) a-bit-trickier-to-explain… as you mention, selectability in text editors is one issue (as with underscores, depending on the editor), but for me it’s also the fact that it reminds me of the syntax reserved for vendor-specific keywords, even if those start with a hyphen as well as having words separated by them.

So this leaves your (1.) and (2.), UpperCamelCase and lowerCamelCase, respectively. Despite the mental link to Java classes (which are, by a more clearly defined convention, UpperCamelCase), CSS class names seem, to me, to be better off starting with a lowercase letter. Perhaps that is because of XHTML element and attribute names, but I guess you could also make the case that having CSS classes use UpperCamelCase would help to set them apart. If you need another reason, lowerCamelCase is what the W3C uses in examples for good class names (though the URL itself, annoyingly, disagrees with me).

I would advise against (4.), (5.) and (6.), for the reasons stated above, but suppose that arguments could be made for either of the other three.

Whether or not you (or anyone else for that matter) agree with me on this matter is up to you though. The fact that you haven’t got a definite answer quoting authoritative sources by now can be taken as a hint that there isn’t such a thing as a definite standard on this issue (else we’d all be using it). I’m not sure that’s necessarily a bad thing.


Emanuil Rusev answered:

Words in CSS class names should be separated with dashes (class-name), as that’s how words in CSS properties and pseudo-classes are separated and their syntax is defined by the CSS specs.

Words in ID names also should be separated with dashes, to match the syntactic style of class names and becaus ID names are often used in URLs and the dash is the original and most common word separator in URLs.


tdammers answered:

It’s mostly a matter of preference; there is no established standard, let alone an authoritative source, on the matter. Use whatever you feel most comfortable with; just be consistent.

Personally, I use css-style-with-dashes, but I try to avoid multi-word class names and use multiple classes wherever possible (so button important default rather than button-important-default). From my experience, this also seems to be the most popular choice among high-quality web sites and frameworks.

Lowercase with dashes is also easier to type than the other options (excluding the hard-to-read nowordseparatorswhatsoever convention), at least on US keyboards, because it doesn’t require using the Shift key.

For id’s, there is the additional practical consideration that if you want to reference elements by their ID directly in javascript (e.g. document.forms[0].btn_ok), dashes won’t work so well – but then, if you’re using jQuery, you’re probably going to use them through $() anyway, so then you can just have $('#btn-ok'), which makes this point mostly moot.

For the record, another convention I come across regularly uses Hungarian warts in ID’s to indicate the element type, especially for form controls – so you’d have #lblUsername, #tbUsername, #valUsername for the username label, input, and validator.


asfallows answered:

I strongly believe the thing that matters most is consistency.

There are two ways to look at this:

  1. A good argument can be made for alllowercase or css-style-clauses (probably the better choice) because they will be the most consistent with the code they’ll be in. It will lend a more natural flow to the code overall and nothing will be jarring or out of place.
  2. An equally good argument can be made for a style that is distinct from HTML tag names or CSS clauses, if it will differentiate IDs and classes in a way that aids readability. For example, if you used UpperCamelCase for IDs and classes, and didn’t use it for any other construct or purpose, you would know you had hit on one every time you saw a token in that format. One restriction this might impose is that it would be most effective if every ID or class were a 2+ word name, but that’s reasonable in many cases.

In writing this answer out I came to find that I’m much more inclined toward the second choice, but I will leave both because I think both cases have merit.