Essas são as 10 regras que eu tento seguir no dia a dia dessa profissão de malucos. E você? Tem suas regras também?

10 rules that will help you with being a good, professional and efficient developer.

1. If it’s hard, it’s wrong.
   If a problem seems too hard to tackle, either you don’t know exactly what you are doing or you are doing it wrong.
   Break down your problem into smaller pieces and try to decouple everything. Writing pseudocode, creating aPoC and talking about your solution to a colleague are great ways to check if you’re going in the right direction.
2. Don’t reinvent the wheel.
   We love coding. Yes, we do. But writing our own solution to everything just because we want it to be exactly like “this” or “that” is a waste of time and money.
   But you should reinvent things from time to time, just for fun. You will understand how things work to the tiniest detail. And you can only innovate or improve on things that you know very well.
3. Never stop learning.
   Programming is hard. Thinking about all possible ways that something can go wrong is exhausting. Dealing with edge cases and crazy users is an insanity. But you will have to spend some time out of that madness to keep learning new things.
   Try a new framework, write pet projects, fill your Github account will endless crap that no one will ever see. That’s gonna be great for your one day, when you face a problem and “Aha, hold on!”, you know how to fix it because you tried that before.
4. Always be clear about what you are doing.
   Don’t start coding until you know exactly what needs to be done.
   There’s nothing worse than someone writing code at random and just hoping it will work at some point.
   That only adds up to a pile of unmaintainable mess.
5. Don’t repeat yourself.
   Reuse everything you can and keep things coherent. But don’t go too crazy either.
   The whole point here is… if you need to change something, you should have to change it only in one place. Otherwise, you will make mistakes.
6. Write tests for everything.
   Not a single line of code should go to production without some form of testing. And don’t trust your coverage either!
   Code Coverage is a lie you tell yourself. Is just code porn.
   Make sure you write a test, then write a line of code to pass that test.
   Only this way you will know for sure that every single thing in your system is tested.
7. Don’t comment, unless you really, really need it.
   Unless something incredibly hard to understand is part of your job, no comments should be tolerated.
   Long if condition? Write the condition to a local constant that explains what’s that.
   Weird algorithm. Write a function name that explains what it does.
   Comments rot, and very fast
8. The best code is no code at all. Code is hard to maintain, so whenever possible, don’t write it. Think how you can make it both more elegant and less verbose, and over time, it will shrink and work better.
9. Always leave the code you changed cleaner than you found it. (a.k.a Boys scout rule of programming)
10. Stick to the rules!
    Discipline will pay off in quality and clarity over time. Things should be black and white: if you establish a rule, follow it to the letter.
    Why? Because you don’t have to think about it. Your precious brain juice is better spent on things that you DO have to think about.

These are basically the rules I try to follow when coding.

—
Also recommended: Watch this series of Clean Code talks from Uncle Bob:

https://www.youtube.com/watch?v=7EmboKQH8lM
https://www.youtube.com/watch?v=2a_ytyt9sf8
https://www.youtube.com/watch?v=Qjywrq2gM8o
https://www.youtube.com/watch?v=58jGpV2Cg50
https://www.youtube.com/watch?v=sn0aFEMVTpA

Update: I found this article with another list of good rules to follow. Check it out!

Update 2: a great checklist for good code

TL;DR: you could use annotations to separate your code and the framework syntax as much as possible.

Update: I’ve created a lib/node module/gulp plugin that converts the comments into AngularJS syntax ☺

— If you want to see it in action, check this project:
https://github.com/darlanalves/angular-repository

In the AngularJS world we have a module system that holds services, controllers, filters, and directives. Services have a little variation of syntax, so we also have factories, values and providers. All this stuff is essential part of the framework’s inner working, and they all have a way to be declared imperatively. Most of them, however, are not really AngularJS “things” but general concepts that we know already from MVC. The code goes like this:

var $module = angular.module('module.name', ['dependency']);

$module.factory('ServiceOne', ['OtherService', function(a) {}]);
$module.filter('filterName', function() {});

AngularJS syntax is not a big deal here, but we have some things that need to be done properly to avoid problems when our code is shipped for production.

One of this things is the array syntax, as seen in the factory above. To make sure the first parameter passed in to the factory is the “OtherService”, we have to annotate it in a specific format, in this case using an array and naming the dependency as string. This is both boring and error prone, also breaking one of the fundamental laws of code: DRY (don’t repeat yourself)!

To circumvent that, we have the awesome ng-annotate project, which does it automagically. But that’s not enough, as we still have to write this imperative declarations everywhere and this code ties the entire project to AngularJS in some way.

So what’s the idea?

I’ve been a PHP programmer before working with AngularJS, and one of the nifty things I did back then was to declare some things with docblocks, like Doctrine entities, event listeners, documentation tags for PHPDoc, and so on.

I also worked with ExtJS, a great framework from Sencha that has a super-duper documentation tool called jsDuck. This tool generates documentation pages right from the source, reading the same docblocks. So, why don’t we use that for AngularJS too?

Instead of writing this AngularJS specific syntax, why don’t we declare it instead to later be parsed with a plugin in your build tool?

The point is: the code should not look like it is written for AngularJS specifically. Check the code below:

https://pastebin.com/KhGQ3SBb

/**
 * @module my.module
 * @requires foo, bar.baz
 */

/**
 * @factory Users
 */
function UsersFactory(DataLayer) {
  return {
    findOne: function (id) {
      return DataLayer.findOne(‘User’, id);
    }
  };
}

/**
 * @filter toDecimal
 */
function toDecimalFilter() {
  return function(data) {
    return parseInt(data, 10);
  }
}

/**
 * @controller UserEditController
 */
function UserEditController(UserService) {

}

Since you no longer have anything that imperatively connects your code with AngularJS, the code becomes cleaner and framework-agnostic. That’s a huge deal in my opinion, since our code becomes nothing but a bunch of functions that create things, much like factories. You just need a tool to convert the comments to code, which is as simple as a docblock parser walking over files. That’s quite easy nowadays with Gulp or Grunt.

If you decide to switch to another framework, obviously directives would be not portable, but they are not meant for that, as they are AngularJS-specific. Other stuff, like services, models, filters or controllers, could all be reused. With a little effort, AngularJS core objects, such as the $injector, $http or $q, could also be replaced with other implementations. I wrote a simple injector just for fun to see how it works. That could be done with the other core services as well. You could even go nuts and replace the $compile service with one that handles the DOM manipulation with a lib like React!

But why annotations? Because the new AngularJS version (2.0) will be using them too, as you can see in this design document or test with the new injector.

To extend the same idea, other small decisions can be taken in a project to completely remove any reference to AngularJS from your code. Think about the utility methods that come with the angular and how you could turn them into a injectable object:

/**
 * @factory util
 * This small object could be replaced with Lo-Dash or Underscore
 */
function toolbeltFactory() {
    var Utils = {},
        methods = 'bind copy equals extend forEach '+
        'fromJson toJson lowercase uppercase isArray ' +
        'isDate isDefined isElement isFunction isNumber ' +
        'isObject isString isUndefined';

    methods.split(‘ ‘).forEach(function(method) {
        Utils[method] = angular[method];
    });

    return Utils;
}

With this small factory, we can start injecting our tool belt as a dependency. This way you never call a method of “angular” anymore, and your project has little to no dependency at all on the framework.

Design should be based on application architecture, not framework constraints ;)

Like it? You should also check the ten commandments of programming!