-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
.editorconfig #314
Comments
Two things.
|
Out of interest, why should tabs be preferred? I didn't know there was a "standard", I've seen both in the wild. |
Yeah, that was my quick estimation on what are the most common settings and what would be the most beneficial to developers. I've seen indentation using spaces around more (and I've been peer pressured to use it), but I don't really lean towards either side in the context of PAWN. As for trimming trailing whitespace, I can't think of any situations where not doing it would be better as the compiler ignores it anyway. In most cases it's just leftover tabs/spaces on empty lines. |
My argument against tabs is most users set the width to 4 and GitHub renders them as 8. Yes, I know "don't use github" but in reality most users in the Pawn/open.mp/SA:MP community use GitHub. It's one of the main places you link and share code. When there's an enumerator declaration or some list of items and it's documented with aligned comments, tabs screw the entire thing up whereas spaces just render as-is. |
Enjoy reading this: https://github.com/Southclaws/ScavengeSurvive/blob/master/gamemodes/sss/core/server/init.pwn#L1090 Compared to: https://github.com/Southclaws/ScavengeSurvive/blob/master/gamemodes/sss/core/server/init.pwn?ts=4#L1090 And no, people will never remember to add ?ts=4 to every single link they share. Given that sampctl is primarily oriented at library authors who are publishing code, I am on team spaces for this. |
Because tabs are what are used in all the official releases - the SA:MP includes and example gamemodes, and tabs are what those people who follow the official conventions use. Yes, some people use spaces instead, but those people are ignoring the official conventions in doing so. So your argument is basically "yes, some people follow the conventions, but some people ignored them, so we should go with those who ignored them". No we absolutely shouldn't - those people are in the wrong. Them having already been in the wrong isn't a reason to continue to promote being in the wrong - we should point people back to the correct method. Using spaces instead would also negate years of trying to explain the use of |
Also, tabs for indentation, spaces for alignment. That libraries that used tabs for alignment look wrong on github by default is IMHO totally irrelevant. |
I disagree with that. SA-MP is just an user of PAWN, so are open.mp, SourceMod and an Estonian satellite, for example. The SA-MP standard library will be barely relevant for people using open.mp. If there's anyone whose example everyone could equally follow, it's Compuphase. Their code style is very inconsistent, however they always use spaces: https://github.com/compuphase/pawn/tree/master/include |
sampctl And I can tell you for a fact that open.mp will enforce tabs to the maximum extent possible. |
Or if the argument becomes that this should be a more generic tool for pawn and not just SA:MP, then the editor shouldn't have that at all. If different users are going to have different standards, then a generic tool for them all can't enforce one. |
Consistency is very important, unfortunately people have taken it the wrong way. The default includes are a little inconsistent, so people have seen that and thought "consistency is important, the default includes are inconsistent, so that means I must be inconsistent as well". That's not what we mean by "be consistent". And no, that's not hyperbole - illidan literally said that to me. |
The main reason is Pawno. There is no easy way to indent code using spaces and not many people (especially considering the user base of Pawno) would be willing to press space four times instead of pressing tab once. Secondly, it converts copied code (once again, the user base of Pawno...) to neither tabs nor spaces. A good example of this is the filterscripts folder of the SA-MP server package: mostly dominated by indentation using tabs, but has nearly 5000 instances of spaces being used instead.
The language guide by Compuphase states the following:
In combination with the fact that even though the coding style of Compuphase is very inconsistent (K&R, Allman, Whitesmiths all within the same standard library), which leaves a lot of room for interpretation, they always indent their code using spaces, it's fair to say that this is how they would write their code in PAWN. If SA-MP had an embedded JVM and used Java for scripting instead, even if it had its own implementation of the entire Java standard library (knowing kalcor it's not as hypothetical as it might sound...), would you use the proprietary standard library as a coding style reference?
Wouldn't this mean that open.mp is the one ignoring the official conventions? |
So why make them?
So we should enforce spaces because something inconsistent that may at some point in the future possibly be supported probably would. Rather than the more consistent, and already supported, system?
Absolutely yes.
No. We are aiming for compatibility with SA:MP and the conventions established there. |
Also, I just checked, github uses
Will change how the files are displayed online as well totally negating that argument. Proof: https://github.com/pawn-lang/YSI-Includes/blob/4.x/YSI_Coding/y_hooks.inc |
Fair enough, in this case I'm okay with going with tabs. However I dislike the fact that you're regarding the SA-MP standard library as the source of truth here. Surely the creators of the language should be deemed more credible? |
Generating a .editorconfig file should be an option when creating a new package. This would help developers avoid some of the common mistakes: using crlf as the line ending instead of lf, saving with the wrong charset and corrupting special characters, mixing tabs and spaces, etc.
The text was updated successfully, but these errors were encountered: