Hey, do you remember Don't do that! flash mini-games?
Last time I got this in video propositions (don’t ask why ) and I was inspired to create this topic …
Some of you while developing a project or just when reviewing pull requests can share most common mistakes made by yours or other developers and I would like group all bad practices into one topic.
Here are my propositions:
Tests and repository branches
When working in group there should be at least one well tested branch, so others could create their own feature branches based on stable one without getting big number of failed tests and searching if our part works as expected. Be sure to test most insecure parts of your code especially user input and data fetched from 3rd-party services or devices.
Log levels in mix environments
You should configure test environment to use at least :info logger level, because in some cases it’s really uncomfortable to searching errors between huge :debug logger messages. It’s better to always use :debug level for logging when you have bigger number of messages or you are logging bigger inspected data.
Try to keep your code clean with only one style
Feel free to create your rules or follow already created style guides. If possible then use tools to check your code style.
Variable names
Please do not use too small names for variables especially one letter names. Also it’s sometimes helpful if you describe unbound variables like: _what_it_could_be.
Don’t give up!
Solution of your problem is waiting for you … at least in this awesome forum
Your review pull requests as normal, eventually marking them as “LGTM” instead of merging them into master directly (you can use GitHub’s support for “required status reports” to make sure noone accidentally does an unchecked merge). It goes through batches of approved PRs, locally merging them with master and testing the combined whole. If the tests pass, it fast-forwards master onto the now-known-to-pass-all-the-tests version. The result is an “evergreen master.”
I am going to have to disagree with this one. I think as long as the variable represents what it holds, it is fine to use small variable names. Even if they are only a single letter. While I generally agree that a single letter is usually insufficient to tell you what the variable does, I can come up with non-trivial use cases for small variable names.
Anything in the realm of mathematics where single letter variable names is common place. Such as if I were to create a graphing library, I would probably represent a point as a two element tuple (assuming 2d graph) being {x, y}. This would be the same if I needed to track a users location within a game or something.
Basically, my general rule comes down to this. The name of something needs to make sense within the scope it is available. This is why I try to make my public functions be as specific as possible so there should be little confusion about what they do within the system. Whereas my private functions really only make sense in the context of that module. And my variable names may only make sense within the context of the function they belong to.
Firstly variable doesn’t do anything - it’s not a function
By small names I mean that I do not want to validate all variable names length same in all projects.
Of course every rule has it’s own exceptions
Firstly length of variable should depend on function complexity. In small functions we could declare variables with one letter name, but:
In your case (point) it could be better if you declare a %Point{} struct.
In more complex methods x could mean for example: unknown variable in the equation and/or point x, so it’s better to name them better.
The best example for what you write are mathematical formulas like:
defmodule Math
@doc """
a^2 + b^2 = c^2
"""
def pythagoras_theorem(a, b)
do: :math.sqrt(:math.pow(a, 2) + :math.pow(b, 2))
end
) and I was inspired to create this topic …
