Want to Drive Innovation through Crowdsourcing? Learn the 5 Steps Get the eBook ×

A #Swift Series Part 1 – Sins of Nonsensical Syntax

By wwwtc In Uncategorized

Posted July 7th, 2015

Hi topcoder community,

My name is Edward Xiao, and I’m the new Online Marketing Intern for TopCoder. This summer, I’ve undertaken the task of learning Swift and tracking my progress via blog posts. In the end, I aim to get a solid grasp of the language, create a functioning, usable product, and inspire you to learn Swift as well, whether you’re a seasoned programmer or a beginner.

To do this, I’m enrolling in Treehouse’s “iOS Development with Swift” track. Personally, I’m not the most experienced programmer out there. My education in programming only began this past winter, when I enrolled in my school’s Python course. After that, I took a web development course, where I learned HTML, CSS, and Javascript, and touched upon Bootstrap, nodeJS, and SQLite. I didn’t blow through the courses and completely master them, but I was certainly competent (or so I’d like to think – that I successfully passed the classes and created fully-functioning programs suggests that this may be plausibly true). As a result, this blog won’t be filled with the most advanced technical writing – I want it to be both accessible to programming neophytes and enjoyable for those who have been coding for a while.

One of the first things I noticed in Treehouse’s Swift tutorial is that they make a note to talk about camelCase. If you don’t already know about camelCasing and would like to know it inside and out, you can reference Wikipedia for more information. Otherwise, camelCase is essentially the process of capitalizing certain letters in compound words for increased readability. In coding, camelCase is leaving the first letter lower case and then capitalizing the first letter of each subsequent word. An alternative to this would be PascalCase, in which each first letter is capitalized, giving us another way to make our code more readable:

There are other ways to make your code prettier, such as using underscores, but the fact that this was brought up highlights a very important aspect of coding: your code should be readable. In my experience, beginner programming classes don’t stress proper code convention enough, which can make coders form bad habits. Often times, when reading other people’s programs that aren’t written in a particularly legible manner, they look something like this:

It’s not terribly hard to infer what s, m, and h mean (although there is a joke to be made there), but when your code inevitably becomes more complex, those kinds of undescriptive names will come back to bite you.

I think it’s the relative simplicity of beginner programs that fosters bad naming conventions. Because we’re usually the only ones working on our code, and our code doesn’t really have a lot of moving parts, we’re free to name our variables whatever we want to. In my Python course, my friend would use his own name for the iterating variable in for loops:

His name isn’t actually Johnny, but the point still remains.

I wouldn’t really have much trouble reading his code, although it was always a weird hitch to see him iterate using his own name. I can’t imagine how annoying that would be in a complex program thousands of lines long, though (funnily enough, he was a better programmer than I was). You could certainly make the argument that this oversight in terms of proper coding convention was a pitfall in my class, but for large public schools, things always fall through the cracks. The rush of the curriculum due to time constraints demands that we cover all the material they want us to cover, even at the cost of emphasizing something as important as learning how to name your variables correctly. Nevertheless, proper naming convention is still important, and should never be overlooked.

For now, that’s all of my insights and opinions. I still have much to learn, so I have to get back to that so I can make sure I write all of this for you guys. Thanks for reading. Stick around for the next installment if you’d like, or don’t. But if you don’t, you best be learning Swift instead.