no-unnecessary-concat questionable recommendations?
See original GitHub issueIn testing out v1.0.0 of ember-template-lint, we noticed the no-unnecessary-contact
rule making recommendations like changing href="{{foo}}"
to href={{foo}}
. We’re not entirely sure this is correct and wanted to bring it up for reevaluation to see if this rule needs refinement or if we’re misunderstanding what is the recommended best practice here.
cc: @rwjblue
Issue Analytics
- State:
- Created 5 years ago
- Comments:13 (10 by maintainers)
Top Results From Across the Web
pandas dataframe concat is giving unwanted NA/NaN columns
I would create a dataframe df_a with the correct columns directly. With a little refactoring of your code, it gives import pandas a=[['Date' ......
Read more >Solved: Concatenate in YANG definition - Cisco Community
Solved: Hi, Does anybody know if it's possible to concatenate the output of one leaf with a substring in another leafref.
Read more >concat for strings be a good addition to the Standard Library?
My point here is: there is no way to do it overhead-free from user code. Even if the code with little overhead is...
Read more >Clang-Tidy Checks
Clang-Tidy Checks¶ ; abseil-duration-subtraction, Yes ; abseil-duration-unnecessary-conversion, Yes ; abseil-faster-strsplit-delimiter, Yes ; abseil-no-internal- ...
Read more >C++ Core Guidelines - GitHub Pages
constructor: invariant – establish invariant – throw – default – not needed – explicit – delegating – virtual; derived class : when to...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
We do already have a rule in the recommended set for preventing this:
Its primary point is to require either quotes or mustaches (this prevents the
<FooBar @blah=derp />
style of issue I mentioned in those linked issues above). It does not take a side RE: which one to use though.no-quoteless-attributes
to recap:
ultimately it comes down to whether we consider this to be primarily a formatting/code style thing, or if this prevents actual issues. I tend to agree by now that this might be the former, so as long as we do not introduce the opposite rule as a default or make “folks should be using quoted attributes” a general rule, I guess I’m fine with removing it from the default set.