Posted on

Coding Standards

Are you one of those developers that use to write code in some sort of cypher, whose only you understands, afraid of being ripped off of your code or seeing your job terminated?

Hopefully you will read this through because I have bad news to you.

To the rest of you, please continue. You will find value for sure.

WordPress community uses the tagline “code is poetry“. I rather think of code as a good prose, written with attention, using decent punctuation and with no hidden sense. Basically, going through all the “clean code” mantras.

Standard (male noun), which serves as a model or reference.

By definition, everything that may serve as a model or reference enabling consistency might be called a standard. Therefore, a standard may be just a coding guide style; or some well proofed formulas to specific problems, known as design patterns.

Standards adoption allows a better code readability. This means, your code will be more easy to be read by others. Contrary to the initial premise, more eyes over the code will improve the detection of bugs, security and performance flaws. This will also diminish the feeling of sole ownership, allowing a better knowledge share among the entire team. No, nobody will take your place…in fact, you will improve chances to become a better developer, and that will help you keep that job longer.

(Source: Rose-Hulman – Institute of Technology)

Design patterns aren’t a new thing, they exists quite some time and there’s an amazing book, written by the gang of 4 – Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides – “Design Patterns: Elements of Reusable Object-Oriented Software“.

However, in this post I intend to focus more on style guides.

At log, we daily use PHP and WordPress, JavaScript, CSS and HTML. I think that every single programming language has its own coding style guide.

There’s a project called “PHP Framework Interop Group” where are debated which standards will be enforced by the PHP community. Related to style guides we have the PSR-1 (Basic Coding Standard) and the PSR-2 (Coding Style Guide). There’s a proposal for a new standard, the PSR-12 (Extended Style Guide) but it’s a draft in early stages.

WordPress, although its codebase is PHP, suggests a different style guide – WordPress Coding Standards – whom collides with the PSR-2. If your intent is plugin or theme development, or say you want to collaborate for the core codebase, you better respect the WordPress style guide.

In our team we follow the WordPress Coding Standards, but we added some rules of our own. Please, be free to read, use or contribute in our github.

Many times, if not the majority of times, this sort of projects born inside companies that may not be directly related with the creation of the language or framework (or CMS). JavaScript Coding Style Guide by airbnb is a good example of it. One of many advantages of Open-Source software for sure. The project is born inside some company and its ownership belongs to the World since there are many external collaborators working in its maintenance and evolution.

CSS related, there are many methodologies like BEM (Block Element Modifier), which one we use at log.

Bottom-line, it does not matter if you will adopt the style guide A or B, but if any will be adopted by your entire team. That’s the biggest challenge and where the major benefits will arise. The feeling of share ownership will increase code quality. Better code quality will decrease the number of bug reports. Better code will be easy to maintain. Better code will enable your system to be more mature and stable. A better system will make you more proud of your work and soo as your employer.

As you see, the entire team will benefit, and so will you.

Posted on

eXtreme Programming

climbing

eXtreme Programming (XP)

90’s

The 90’s was the stage for a revolution on the software development processes and methodologies. A cry for help against the Waterfall methodology, the micro-management processes and the extreme burocracy that made software development slow and low-productive. Some years before SCRUM was blueprinted. The Agile Software Development Manifest would be born in 2001, from the work of Jeff Sutherland, Ken Schwaber and Alistair Cockburn. But this subject will take another article.

Year 1996

Kent Beck, a software engineer that would subscribe the Agile manifest, creates the eXtreme Programming (XP) methodology – designation supported because it is a methodology in which their processes are taken to the extreme.

Basic principles like fast feedback, simple design, incremental changes, embracing changes and high quality work are defend by the five XP’s core activities:

  • Planning
  • Management
  • Design
  • Coding
  • Testing

I consider those processes inherent the last two activities are of extreme value for the quality of the developed code and an important tool for the health of a software development team (notice: the health within a team demands more tools that will be addressed in separate articles).

My talk – easing a hurricane called TEAM – was based on those last two activities.

I will publish a collection of articles about those rules:

  1. Standards
  2. Test-Driven Development
  3. Code Review
  4. Pair Programming
  5. Continuous Integration

 

Until then, happy coding.

Posted on

easing a hurricane called TEAM

Meetup WordPress Porto

I had the pleasure to attend the WordPress Oporto’s Meetup. A group of geeks that get together monthly, uninterrupted for 4 years and counting. Travelling to the beautiful city of Oporto is always a pleasure, even if the distance from Lisbon goes past 300km.

“easing a hurricane called TEAM“

My presentation’s title. This talk starts with a brief travel on some moments of my career as a software developer. With some much needed passages on some “dramas”, which without those, I wasn’t what I am today. Those moments also enabled me to connect with some of the best professionals in the field. Some, I have the pleasure to call friends nowadays.

With them I learned what SCRUM and eXtreme Programming was and, the real importance of a CTO as a human being.

Years gone by, I see myself in that place, leading a software development team in a company that permits the usage of some of those eXtreme Programming best practices.

The second half of my talk goes on those best practices (coding standards, code review, test-driven development, continuous integration, continuous delivery), what they do daily to my team and for my team.

Next November 2nd I will have the opportunity to revisit this presentation, now at Lisbon in the change.log meetup.

Hope to catch you there.

Posted on

Back to the beginning – Murphy’s Law

blacksmith’s house, wooden skewer

In Portugal we have this proverb. As much as I hear this, I will never internalize it properly.

In our field we have one, and only one certainty – What might go wrong, will go wrong.

Is there a developer that never heard of Murphy’s Law? Or that, in a specific sensitive moment, wished with all his body that Murphy could not find him?

I decided to delete, from my hosting, all my ancient projects’ databases. Playing by the book, I made backups in first hand and DROP DATABASE ...

I deleted all databases, except two. I only have two projects in my hosting, my blog and my brother’s blog. I watched in awe an error connecting to database when I tried to access both blogs.

“Ok, I probably mistakenly switched names. Will restore them with my backups.”, so I thought. “Evil” Murphy found me while I was performing the backup operation, because those files were corrupted.

I bet that even you think “that only happens to others”. Yeah, I think the same always, but this time I’m screwed. Let’s start this blog thing from scratch.