Since there is no measurable performance advantage for either, any time (however marginal) spent thinking or talking about a choice between the two is wasted. When you prefer single quoted strings, you have to think when you need interpolation. When you use double quoted strings, you never have to think. (I'd also add, anecdotally, that apostrophes are more prevalent in strings than double quotes, which again means less thinking when using double-quoted strings.) Therefore always using double-quoted strings results in the least possible wasted time and effort.

I don't like the first syntax because then you have weird looking code due to all the leading whitespace, and you lose a lot of real estate.

Aligning everything with however long the method name is makes every indention different. belongs_to :thing, class_name: 'ThisThing', foreign_key: :this_thing_id has_many :other_things, class_name: 'ThisOtherThing', foreign_key: :this_other_thing_id validates :field, presence: true Compared to the following, which all align nicely on the left. belongs_to :thing, class_name: 'ThisThing', foreign_key: :this_thing_id has_many :other_things, class_name: 'ThisOtherThing', foreign_key: :this_other_thing_id validates :field, presence: true

This one bugs me a lot, but honestly, I don't like either style of the "normal method calls" above. I'm definitely voting to change the rule, but I'd also recommend trying to use the following syntax. In my opinion, it's the best of both worlds. a_relatively_long_method_call( :thing, :another_thing ) Or, if there are a lot or arguments, or the arguments are long: a_relatively_long_method_call( :a_long_argument, :another_long_argument, :a_third_long_argument )

Prefer alias when aliasing methods in lexical class scope as the resolution of self in this context is also lexical, and it communicates clearly to the user that the indirection of your alias will not be altered at runtime or by any subclass unless made explicit.

For example, whereas C programmers have argued for years about where to put their brackets, and whether code should be indented with tabs or spaces, both Rust and Go eliminate such issues completely by using a standard formatting tool (gofmt for Go, rustfmt for Rust) which rewrites your code automatically using the canonical style. It’s not that this particular style is so wonderful in itself: it’s the standardisation which Rust and Go programmers appreciate.

I only allowed smaller closures in the code and refactored the rest into separate top-level functions. This is a deliberate move against the common practice of js programmers. Why? Because I noticed closures make code harder to read.

I am not sure if this is an improvement. To me it does not seem very pretty. Of course I am biased since I also prefer () in method definitions if they have arguments; although I think it is fine that ruby does not mind omitting the (). For my brain, I like the () for visual separation.

( user_id int , user_name varchar , last_activity timestamptz )

“Who cares? Let’s just go with the style-guide” — to which my response is that caring about the details is in the heart of much of our doings. Yes, this is not a major issue; def self.method is not even a code smell. Actually, that whole debate is on the verge of being incidental. Yet the learning process and the gained knowledge involved in understanding each choice is alone worth the discussion. Furthermore, I believe that the class << self notation echoes a better, more stable understanding of Ruby and Object Orientation in Ruby. Lastly, remember that style-guides may change or be altered (carefully, though!).

“It is less clear that way” — that is just arbitrary, even uninformed. There is nothing clearer about def self.method. As demonstrated earlier, once you grasp the true meaning of it, def self.method is actually more vague as it mixes scopes

When we usedef self.method, though, we are defining a method across scopes: we are present in the regular class scope, but we use Ruby’s ability to define methods upon specific instances from anywhere; self within a class definition is the Class instance we are working on (i.e. the class itself). Therefore, usingdef self.method is a leap to another scope, and this feels wrong to me.

Similarly to fashion, code style reflects our credo as developers, our values and philosophy.

Yet, it certainly is important to make the proper choices when picking up style. Similarly to fashion, code style reflects our credo as developers, our values and philosophy. In order to make an informed decision, it’s mandatory to understand the issue at stake well. We all have defined class methods many times, but do we really know how do they work?

The problem is that not all tooling supports adding new dependencies from a transform. The first step is figuring out how this can be done idiomatically in the current ecosystem.

However, know when to be inconsistent -- sometimes style guide recommendations just aren't applicable.

The limits are chosen to avoid wrapping in editors with the window width set to 80, even if the tool places a marker glyph in the final column when wrapping lines.

For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay to increase the line length limit up to 99 characters

it also allows for more divergence in how people write there code and where they put their logic, making different svelte codebases potentially even more different due to fewer constraints. This last point is actually something I really value, I read a lot of Svelte code by a lot of different people and broadly speaking things look the same and are in the same places.

“I came to Rust from Haskell, and I feel that Haskell is a very elegant and safe language. The biggest differentiator for me is that there is a greater difference between high-performance code and idiomatic ‘clean’ code in Haskell than in Rust. Most Rust code looks like most other Rust code, even when it performs well. Haskell can become unfamiliar real quick if someone is operating under different libraries and goals from what you are typically doing. Small differences in syntax can result in huge differences in behavior, and Rust has more uniformity on that axis.”