“readability” is subjective. much like how there is no objective definition of “clean code”. i am not arguing that either option is more generally “readable”, i am insisting that people use a common standard regardless of your opinion on it. a bad convention is better than no convention. i dont personally like a lot of syntax conventions in languages, whether that be non-4-space indenting, curly braces on a new line, or early-declared variables. but i follow these conventions for the sake of consistency within a codebase or language, simplicity on linter/formatter choice, and not muddling up the diffs for every file.
if you want to use <br/> in a personal codebase, no-one is stopping you. i personally used to override every formatter to use 2-space indenting for example. but know that there is an official best practice, which you are not following. if you work in a shared codebase then PLEASE just follow whatever convention they have decided on, for the sake of everyone’s sanity.
if you work in a shared codebase then PLEASE just follow whatever convention they have decided on, for the sake of everyone’s sanity.
That goes without saying; I’m not a barbarian.
“readability” is subjective. much like how there is no objective definition of “clean code”.
Did you not see the part where I said it’s less readable “in my opinion”?
i am insisting that people use a common standard regardless of your opinion on it.
I can read this one of two ways: either you’re making an assertion about what people are currently doing, or you’re telling me/others what to do. In the first case, you’re wrong. I’ve seen many examples of self-closed <br> tags in the open source projects I’ve contributed to and/or read through. In the second case, IDGAF about your opinion. When I contribute to an existing project I’ll do what they do, but if I’m the lead engineer starting a new project I’ll do what I think is the most readable unless the team overwhelmingly opposes me, ‘standards’ be damned, your opinion be damned.
The spec says self-closing is “unnecessary and has no effect of any kind” and “should be used only with caution”. That does not constitute a specification nor a standard - it’s a recommendation. And I don’t find that compelling. I’m not going to be a prima donna. I’m not going to force my opinions on a project I’m contributing to or a team I’m working with, but if I’m the one setting the standards for a project, I’m going to choose the ones that make the most sense to me.
If a spec tells me I should do something that makes my code less readable in my opinion I am going to ignore the spec every time.
There’s even one in English that I actively and pointedly flout: punctuation must go inside of the quotes if the quote terminates the sentence
Yeah, unless it’s a formal setting, reader comprehension comes before all else
“readability” is subjective. much like how there is no objective definition of “clean code”. i am not arguing that either option is more generally “readable”, i am insisting that people use a common standard regardless of your opinion on it. a bad convention is better than no convention. i dont personally like a lot of syntax conventions in languages, whether that be non-4-space indenting, curly braces on a new line, or early-declared variables. but i follow these conventions for the sake of consistency within a codebase or language, simplicity on linter/formatter choice, and not muddling up the diffs for every file.
if you want to use
<br/>in a personal codebase, no-one is stopping you. i personally used to override every formatter to use 2-space indenting for example. but know that there is an official best practice, which you are not following. if you work in a shared codebase then PLEASE just follow whatever convention they have decided on, for the sake of everyone’s sanity.That goes without saying; I’m not a barbarian.
Did you not see the part where I said it’s less readable “in my opinion”?
I can read this one of two ways: either you’re making an assertion about what people are currently doing, or you’re telling me/others what to do. In the first case, you’re wrong. I’ve seen many examples of self-closed <br> tags in the open source projects I’ve contributed to and/or read through. In the second case, IDGAF about your opinion. When I contribute to an existing project I’ll do what they do, but if I’m the lead engineer starting a new project I’ll do what I think is the most readable unless the team overwhelmingly opposes me, ‘standards’ be damned, your opinion be damned.
The spec says self-closing is “unnecessary and has no effect of any kind” and “should be used only with caution”. That does not constitute a specification nor a standard - it’s a recommendation. And I don’t find that compelling. I’m not going to be a prima donna. I’m not going to force my opinions on a project I’m contributing to or a team I’m working with, but if I’m the one setting the standards for a project, I’m going to choose the ones that make the most sense to me.