Review the coding style

[naipotato]

Review the coding style

[naipotato]

Another thing to add here is that maybe we should stop using --enable-experimental-non-null as it makes the code more fuzzy and harder to read (mainly due to Vala lacking this)

[naipotato]

A link to the Vala coding style => https://wiki.gnome.org/Projects/Vala/Hacking#Coding_Style

[lifeiscontent]

@nahuelwexd I'd prefer the coding style of Vala, e.g. you wouldn't want to read ruby style code in JavaScript. It also eases the eyes of potential readers of the code since that's what they'll probably be familiar with anyway.

[naipotato]

@lifeiscontent I was previously following a coding style more similar to C# because it was a little more practical to read (more spaces), plus the Vala being inspired by C#, it was still partly familiar

[lifeiscontent]

Makes sense, another idea you could do is add something like vala-lint to pre-commit hooks, that way you don't need to think about it and formatting is automatically taken care of for you. I wish Vala had something like prettier so you could just run it along side your editor in real time.

[naipotato]

@lifeiscontent It's a nice idea, but vala-lint AFAIK does not lint your code. Currently just throws errors if your code is not following the style defined in the config file

[naipotato]

What do you think of this coding style? It's heavily based on the elementary's coding style, since most of the current Vala code comes from there.

• Whitespace before opening parentheses or braces
• Whitespace between numbers and operators in math-related code
• Closing brackets must be followed by an empty line, except when followed by an else statement
• 4 column wide tabs for indentation and spaces for alignment
• "One True Brace Style" (1TBS) for classes, functions, loops, and general flow control
• Mandatory braces, even with single line blocks
• Cuddled else
• switch...case instead of multiple else if
• 1 public class per file.
• Same name for file as for its public class, but in kebab-case
• Descriptive names for everything
• // for comments
• /// TRANSLATORS: for translators annotations
• snake_case for variable and method identifiers
• PascalCase for type identifiers
• SCREAMING_SNAKE_CASE for enum members and constants
• Static type casting over dynamic type casting
• Properties over getters/setters
• Object initializers to avoid redundancy. See:

  // bad
  var label = new Gtk.Label ("Test Label");
  label.ellipsize = Pango.EllipsizeMode.END;
  label.valign = Gtk.Align.END;
  label.width_chars = 33;
  label.xalign = 0;
  
  // good
  var label = new Gtk.Label ("Test Label") {
      ellipsize = Pango.EllipsizeMode.END,
      valign = Gtk.Align.END,
      width_chars = 33,
      xalign = 0
  };

• Implicit GLib namespace
• String templates over printf-style, except for error messages, as they must be localized.
• 120 columns per line
• 1 argument per line when breaking long method calls
• GObject-style construction when possible
• this prefix to refer to current's instance members
• Operators over methods when method has syntax support
• public only when necessary, private otherwise
• Underscore prefix for private fields
• Auto-implemented properties when possible. See:

  // bad
  private string _name;
  public string name {
      get {
          return this._name;
      }
      set {
          this._name = value;
      }
  }
  
  // good
  public string name { get; set; }

• Implicit type only when obvious. See:

  // bad
  var result = ExampleClass.result_so_far ();
  
  // redundant => bad
  Person person = new Person ();
  
  // good
  ResultSet result = ExampleClass.result_so_far ();
  
  // good
  var person = new Person ();

• Newlines to separate the code into logical pieces

[lifeiscontent]

@nahuelwexd I'm a fan of this. I'd say lets do it!