Apologies for the bluntness, but if you cannot conform to the coding standards of a
project in terms of minor things such as spacing, how can we know or trust you that you
are confirming to standards that are more meaningful, such as those related to security?
Standards allow for a consistent appearance of the codebase both on an aesthetic and
functional level. On the aesthetic side of things, we strive for code that is easy for
humans to read and understand in order to assist in code reviews. Having a single defined
standard to achieve that also adds a level of consistency and professionalism to the
codebase. While I personally believe MediaWiki's style is too spacey, I understand the
value in having all code conform to the standard and as a result I conform to it when
coding for MediaWiki. I encourage you to look for and understand the value of a single
standardized style as well as opposed to each developer coding however it suits them.
On the technical side of things, consider merging in changes to someone else's work --
if your style clashes with theirs the result will look horrible and as a result be harder
to read and understand. And if someone else comes back and makes an edit in somewhere
slightly nearby, you'll have to deal with annoying merge conflicts due to whitespace
issues instead of git just intelligently merging it all together automatically.
On Oct 14, 2015, at 10:42 AM, dinar qurbanov <qdinar(a)gmail.com> wrote:
How would it
help the reviewer if they constantly need to
switch their mind from "prettified" code to "whatever" when
they review your code?
it is possible to show prettified code in gerrit web pages, and send
prettified version to people if they get it via git fetch, but save
also their original form .
and, as another alternative, it is possible to save original form in
author's computer, and automatically prettify it in gerrit server just
after he pushes it into gerrit...
If you don't want to press the space bar, you
can always in-
tegrate stylize
(
http://git.wikimedia.org/blob/mediawiki%2Ftools%2Fcode-utils.git/master/sty…
)
in your workflow or amend your editor to insert the spaces
when you type.
then i would need to see that prettified code at my further local
editions and sometimes i would have to manually delete that extra
spaces during editing my code.
2015-10-14 20:23 GMT+03:00 Jon Robson <jdlrobson(a)gmail.com>om>:
FYI if you are talking about JavaScript you might
want to explore
http://jsbeautifier.org/
All code standards are currently being enforced by jscs.
They recently closed an issue to add auto-formatting
https://github.com/jscs-dev/node-jscs/issues/516
In theory, you could create a script to autoformat your code and write it
in any style that appears comfortable to you. It would be useful for
someone to explore this and comment back on results.
We should be wasting less time on the appearance of code - making sure it
adheres to standards - and instead focusing on the contents of its code.
On Wed, Oct 14, 2015 at 9:39 AM, Tim Landscheidt <tim(a)tim-landscheidt.de>
wrote:
dinar qurbanov <qdinar(a)gmail.com> wrote:
i think i lose my individuality and that i have
to make extra key
presses to set extra spaces near brackets and commas. currently tests
/ automatical reviews show in gerrit that my commit has such errors.
what if they are not (would not be? were not? ) blamed on commit
(patch set) uploads, but only automatically prettified/standartised
at/before actual commit/merge?
and, by the way, i think, should not they even be
saved as they are
written and should not, instead, diff tools automatically standartise
them before calculating difference?
How would it help the reviewer if they constantly need to
switch their mind from "prettified" code to "whatever" when
they review your code?
If you don't want to press the space bar, you can always in-
tegrate stylize
(
http://git.wikimedia.org/blob/mediawiki%2Ftools%2Fcode-utils.git/master/sty…
)
in your workflow or amend your editor to insert the spaces
when you type.
Tim
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
Jon Robson
*
http://jonrobson.me.uk
*
https://www.facebook.com/jonrobson
* @rakugojon
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l