Tag: Code Style (Page 1 of 2)

HTML Code Styles: What Are Your Strategies? – Part 2

September 10, 2013 / Tom / 0 Comments

This is a follow-up post to one that I originally wrote in December 2012. Be sure to read it, as well!

Months ago, I wrote a post on some of my preferred HTML Code Styles during which I shared two specific things that I do whenever I am writing markup.

Specifically, I do the following things:

Comment Terminating Tags
Underscore Class Names

When it comes to writing code, there are always going to be standards – well, at least there should be – that depend on the proverbial sandbox in which we’re playing.

These standards will outline certain things that we should do, but there are always bound to be gray areas. Case in point: I know people have often commented (no pun intended) that they aren’t a fan of the way that I terminate certain closing blocks with comments such as `// end if` or `// end while` or `// end class`.

Which is completely fine – to me, that’s an example of a gray area that gives us, as developers, room for implementing our own unique styles. But then there are others that really should be reconsidered.

And that’s what I’ve had to do with some of my markup styles.

Object-Oriented WordPress Plugin Development

February 21, 2013 / Tom / 0 Comments

When it comes to writing plugins – specifically those that are object-oriented in nature – many of us do so because we’re obviously fans of writing object-oriented code.

Personally, I’m a fan of it because it helps to separate the responsibilities and concerns of a requirement into its own logical unit.

Sure, this can be done with several function files as well, but I come from an object-oriented background, so when I approach a problem, I automatically begin thinking in terms of classes and their relationship to one another.

And I know that other developers do the same.

The thing is, I think some of us – myself included – have gotten lazy or we only half-bake our object-oriented-based plugins. That is to say that we may be using classes in writing our plugins, but we don’t do such a good job of taking advantage of other object-oriented principles and features.

WordPress Refactoring: Refining Plugin Functions

February 13, 2013 / Tom / 0 Comments

Whenever it comes to writing code – be it starting a new project or working with an existing system – there are a lot of developers that aim to write clean, maintainable code.

It’s a challenge for sure, but it’s not impossible. Even if you’re responsible for simply introducing a new function into an existing system, there’s an opportunity to leave the place a little better than you found it.

Granted, trying to refactor a larger system too much can have serious unintended consequences, so I don’t necessarily advocate doing that, but if you have the opportunity to break a one larger function into several smaller, more focused functions, then I think the opportunity should be taken.

I recently had a chance to do a bit of WordPress refactoring in the context of a commissioned plugin I am working on, and wanted to share the process that I followed for doing so.

We Need Better Abstraction in WordPress Projects

January 24, 2013 / Tom / 0 Comments

When it comes to programming – regardless of the platform, language, or system that you’re using – there’s a concept of abstraction that most programmers understand even if they don’t know that that’s what the concept is called.

Perhaps the clearest definition on abstraction in programming (straight from Wikipedia) explains:

Abstraction is the process by which data and programs are defined with a representation similar in form to its meaning (semantics), while hiding away the implementation details.

A simple, practical example of an abstraction would be the concept of functions: It completes a unit of work and optionally accepts parameters and returns data to the caller

The details are implemented – are abstracted – into the function so that other programmers (or even the original developer himself or herself) can simply make a single call to the function.

Easy enough, right? Especially since we’ve all written functions.

Of course, abstractions can be more complex. Starting from functions, moving up to classes, moving up to full API’s and so on. Everything in programming lives at some level of abstraction.

I bring all of this up because I’ve seen – and continue to see – huge opportunities for refactoring WordPress-based code (specifically in themes and plugins) into more abstract units in other code as well as my own.

Why I Terminate Blocks with Code Comments

January 17, 2013 / Tom / 0 Comments

Thanks to a number of open source contributors, I released WP Audio Player 1.3 to the WordPress plugin repository. For one of the pull requests, I mentioned the following:

I always terminate my blocks with a closing comment. Please keep this in the file.

Travis Northcutt also asked me about it via Twitter:

@tommcfarlin curious about always terminating blocks with a closing comment – what's the rationale there?

— Travis Northcutt (@tnorthcutt) January 14, 2013

When it comes to writing code, I try hard to make sure that anything I do that’s outside of the normal coding conventions for a given platform has a rationale behind it.

Case in point: Ending my terminating braces with code comments.