Open PhoenixZeng opened 5 years ago
1: Is it necessary to alert for grammatical inconsistencies?
I'm not sure what you mean by "grammatical inconsistencies". In general warnings try to incentivise following Coding Conventions.
I find that there are more and more warning objects in Wurst now. I am afraid that the use of space will also be warned in the future.
We are adding more warnings, but I'm not sure what you mean by "space being warned". The last update regarding spaces/tabs actually allows more flexibility (2-space indentation now also works) than before. The only thing being warned is if you mix them, which you really shouldn't do.
It's good to follow certain grammatical standards, but warnings about them can break some people's grammatical habits (not for me, I'm a Java programmer). For example, vjass users habitually capitalize function names
vJass teaches bad habits and people should adjust their behaviors to the better instead of clinging to old ones imho. It's just like wanting to write C-like code in Java. Why are you trying to fight the compiler/language in the first place?
2: If you feel that Thing-1 has no plan to modify, can we suppress a warning for some packages?
Yea I think adding configuration would be good, even tho it opens the possibility to people just disabling everything ;)
space
mean aaa()
and aaa ()
and aaa( )
vJass teaches bad habits and people should adjust their behaviors ...
i think it base on common.j
and blz.j
and this is a language-specific habit. not good or bad.
Why are you trying to fight the compiler/language in the first place?
not a fighting. I just think even if there are code specifications, there should be not warning it.
(in fact . i use c-like{}
in java .eg:int aaa()\n{\n\t\\body\n} )
Yea I think adding configuration would be good...
great!
i get 44 warns in my lib now. They have the @ifNotDefined
,so the func-sign cant modfly
mean
aaa()
andaaa ()
andaaa( )
Yea, I think those should be warnings as well. Just like TSlint.
i think it base on
common.j
andblz.j
and this is a language-specific habit. not good or bad.
In a Jass environment it might make sense. In wurst it is not coding convention and therefore bad because uppercase IDs indicate non-function type or native (which shouldn't be used 99%).
I just think even if there are code specifications, there should be not warning it.
Then there isn't much point in having them though.
(in fact . i use c-like
{}
in java .eg:int aaa()\n{\n\t\body\n} )
Using linebreaks before opening curly braces should be a criminal offence 😄
Using linebreaks before opening curly braces should be a criminal offence
While complying with code specifications, everyone still has some personal habits.😄
just like 4 or 2 space
and space or tabs
Yea, I think those should be warnings as well. Just like TSlint
so. i more needs Warning suppression before the space-warn impl-ed😄
It's a headache for me to always follow the wurst grammar guide, especially the lint itself got wrong. Why not simply add a feature to disable the grammar lint? I think this feature should be a personal choice.
The grammar hint always breaks my flow of thoughts, and sometimes it makes me costing time to find out if it's my problem or the compiler.
The grammar hint always breaks my flow of thoughts, and sometimes it makes me costing time to find out if it's my problem or the compiler.
If the warning is really incorrect, you should report that in a separate ticket.
Allow suppression one package's all warning
There are two things I want to discuss here.
I find that there are more and more warning objects in Wurst now. I am afraid that the use of space will also be warned in the future.
It's good to follow certain grammatical standards, but warnings about them can break some people's grammatical habits (not for me, I'm a Java programmer). For example, vjass users habitually capitalize function names
We can enable them to switch in the settings.
Mainly for some libraries migrated from vjass. I always finished migrate by regex-replace by one to two minutes. but need a few minutes for the warnings
Of course, warnings from standard libraries are always painful.