If you’ve ever worked on a large programming project you know all about the joy of trying to read other people’s code. And of course that’s how everyone else feels about reading your code. That’s why formal programming style guides exist — to help bridge the gap between individual styles.
Developer Nicolas Gallagher wants to change that. To do so Gallagher has put together Idiomatic CSS, a style guide for how to format, organize and craft quality CSS that anyone can work with. Here are the general principles of the project:
“Part of being a good steward to a successful project is realizing that writing code for yourself is a Bad Idea™. If thousands of people are using your code, then write your code for maximum clarity, not your personal preference of how to get clever within the spec.” — Idan Gazit
All code in any code-base should look like a single person typed it, no matter how many people contributed.
Strictly enforce the agreed upon style.
If in doubt use existing, common patterns.
If you’ve made the leap to a CSS preprocessor like SASS or LESS, fear not, Idiomatic CSS has you covered as well. Preprocessor syntax varies and Idiomatic CSS offers examples in SCSS, but the more general rule, “your conventions should be extended to accommodate the particularities of any preprocessor in use,” apply to others as well.
Wrangling CSS on large projects can be a pain, but if you take the time to create a set of conventions and ensure that everyone sticks to them it becomes a much more manageable task. If you’ve got experience and insight to share, head on over to the Idiomatic CSS GitHub page and contribute your knowledge.
Students, start your coding engines. Google’s annual Summer of Code program, which helps college students write open source software during their summer vacations, starts today.
Past participants have helped improve everything from popular web frameworks to browser add-ons and even operating systems. Summer of Code is also not a half bad way to get yourself on Google’s radar — the company looks at the results of the program to help it “identify potential recruits.”
Summer of Code has served as a launchpad for quite a few new open source software projects as well as helping to jumpstart work on existing favorites. This year’s roster includes some 1,208 students who will spend the next 12 weeks writing code for 180 different open source organizations.
With 208 proposed projects, there’s a pretty good chance that some Summer of Code improvements will be rolled into your favorite open source projects later this year. Among the things we’ll be keeping an eye on are Metalink’s various efforts to improve the download capabilities in Firefox and Chrome. Eventually Metalink wants to bring error recovery/repair for large downloads to everything from Chrome to wget.
Any good programmer can tell you writing code is an art form, and as with most art forms, the key to success is good habits and lots of practice.
The Ruby Learning blog recently posted an interesting list of ways to improve your code quality and, perhaps more importantly, develop habits that will lead to better code creation. Developer James Schorr’s tips range from the obvious, like using a good version control system, to the more subtle: “realize that just because we “can” doesn’t mean that we “should”… anything’s possible, but not everything’s advisable.”
The article is broken into the three major parts of any programming workflow: pre-development, development and post-development. There are a number of great suggestions in each, but our favorite parts are the fourth category: Enjoying Your Development. Almost any project is fun and enjoyable in the beginning, but then there seems to come that point at which the fun evaporates and we get bogged down in the grunt work of writing code. Schorr has few tips to help break you out of those boring stretches:
Give yourself time to think and rest. There are some days where I just can’t write code well; other days where it’s just flowing. This is due to how your brain functions. You need sleep and a change of pace and scenery now and then.
Walk away for a while. It’s easy to get “tunnel vision” and think that you’re close to solving a problem and to think that more effort will solve it… You would be surprised at the ideas or solutions that will spring into your mind as you are thinking about or doing other things.
Head over to the Ruby Learning blog to read some of the other helpful tips and tricks for producing quality code.
No programmer is perfect, but some mistakes are more dangerous than others. While some mistakes might just slow down your site, others can open up vulnerabilities that expose your code, your database and even your users to all manner of attack.
To help you identify the more serious errors common in programs of all types, a group of top software security experts in the US and Europe have released their Top 25 Most Dangerous Programming Errors.
Unsurprisingly, cross-site scripting vulnerabilities and improperly handled SQL top the list of common and dangerous mistakes. Remember kids, sanitize your database inputs; you just never know when someone is going to name their child: “Robert’) DROP TABLE Students;”
While not all the errors in the list are common in web programming, some of the more serious things are concerns for web developers — cross-site request forgeries, missing encryption of sensitive data and unrestricted file uploads are all common web programming issues.
Also interesting is the weaknesses by language section, which breaks down common mistakes in PHP, Java, Perl and C/C++. No doubt web developers would like to have seen Python and Ruby in that list, but it should at least be useful for PHP and Perl programmers.
Events are user interactions with their computer, such as a mouse click or key press.
In the good ol’ days, computers handled user interactions as input of batched data. The user fed a hunk of data in, the computer did something to that data, then produced the results. With the advent of interactive devices like the GUI interface, computers could display answers to computations onscreen. The input for these interactions are events caused by the user, which could be keystrokes, button clicks, or the position of the mouse pointer.
(see Event Handler).