| Subcribe via RSS

Stamp Out Tab-Stops! (An Unsung Holy War)

August 3rd, 2009 | 2 Comments | Posted in Perl, PHP

At $DAY_JOB, I have for the first time encountered a coding style that I have problems adapting to. It’s not that I can’t do it; I easily re-configured my editors and IDE settings to accomodate it. It just leaves a bad taste in my mouth every time I commit code with tab characters still present.

It’s a quiet holy war, nowhere nearly as loudly fought as Perl vs. Python (Perl, naturally) or Emacs vs. Vi/Vim (I take the Switzerland stance and use both while advocating neither). Do you expand your tabs to spaces? Do you even have tabs at all, have you instead configured your editor-of-choice to bypass them entirely? Do you prefer to retain tabs? Or do you, like the author of these styling guidelines, advocate mixing spaces and tabs together?

To me, that’s the worst of the options– even though you’re using spaces to make sure that sub-elements of a statement still line up, it only takes a few missed lines and a viewer (such as “less”, or converted-printing such as “enscript”) with tab settings that are different than yours. Then, you have source code whose flow is so much harder to read than it needs to be.

And what are the arguments for even using tabs? They’re a hold-over from the days of mechanical typewriters, and some cool steampunk hacks notwithstanding, we don’t use those anymore. Non-software-professional office workers don’t even use them anymore! The closest they come is in word-processing software such as OpenOffice.org or Microsoft Word. Neither of which, last I checked, were popular as source-code editors.

My coding style has evolved over the years, and the way I code now doesn’t always match what I wrote 15 years ago. Sometimes when I look at my older code it can be painful to see stylistic shortcomings. But when I look at code that uses tabs, let alone that mixes tabs and spaces, it’s often outright jarring. Block structures in Java, Perl, even PHP can be all over the place if the author wasn’t careful. And if there were multiple authors, it’s almost guaranteed to be that much worse.

I’ve heard people say, fairly-recently even, that a tab-stop saves bytes over using spaces for the same indentation. Why is this even remotely an argument when terabyte disks are under $200? Is the savings of a few bytes here and there worth the headache of reading code who’s format is skewed by inconsistent tab layout?

I’ve also heard that it’s a matter of keeping people to a consistent style, and that not everyone has their editors set up to convert tabs. That’s an even weaker argument, since even as I started re-learning Vi/Vim, it took me mere minutes to find the proper option to make it always use spaces in place of tabs (that would be “expandtab”, in case you were wondering). In Emacs you can also configure it (because really, what can’t you configure in Emacs?), and likewise it is trivial to set up in Eclipse, Padre, jEdit, etc., whichever editor is your favorite. And consistency in style is so much more than just tabs versus spaces, it seems like an insult to the question of stylistic guidelines to reduce them to this argument. And with tools such as pertidy, there’s no reason to be that concerned about the relationship between editing and style-adherence.

So help me in my goal of stamping out every last tab-stop in source code that you find! End the tyranny of the mechanical typewriter!

Tags: ,

OSCON Day 2, Part 2: Improving Error Reporting

July 24th, 2009 | No Comments | Posted in Conferences, Perl, PHP

(Or, “This is a lot easier to do when I’ve had more sleep the night before.”)

The highlight of the second day, for most if not all in the Perl community, was Larry Wall’s annual “State of the Onion” talk. Larry’s talks are not the kind you can easily summarize with a handful of quickly typed/scribbled notes. The basic gist of it, though, could be summarized as focusing on improving the quality and timeliness of error reporting in Perl 6 and the Parrot grammar/parsing engine. As is usually the case with Larry’s talks, it provided a good deal of food for thought in areas above and beyond the examples that were shown.

As to the rest of the day, for me, it was largely PHP-tastic. The first session I attended was Patrick Michaud’s talk on building compilers with the Parrot Compiler Tools. This session cleared up a lot of questions I had, and I hope to find the bandwidth to explore these tools some over the next few months. The other three sessions I got to were all PHP; one on building distributed systems with PHP (that actually focused more on proper configuration, care and feeding of memcached), one on PHP best practices (which was doubly-interesting in that the pair giving the presentation have been doing it for years, and in their slides they showed how the impression of “best practices” has evolved as PHP itself has), and finished the day with a session on the PHP Xdebug extension. I found this one the most interesting, as I am still such a novice with PHP.

In addition to the above, and as I mentioned in my previous post, I took a leap of faith and did my first-ever lightning talk. These are talks limited (STRICTLY!) to 5 minutes each. You can go back to the previous post for the links to the topic I spoke on, and you can peruse my slides here. (The slides are done using the fantastic S5 system by Eric Meyer. Took me about 3 minutes to get the feel for it and start focusing on actual slides-content.)

Tags: , ,