Skip to content
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

Some manual format improvements #335

Closed

Conversation

@stevenroose
Copy link
Collaborator

commented Oct 8, 2019

I used rustfmt and went over the results, selecting the changes that were in my opinion trivially better.

  • module and use sorting
  • remove awkward extra spacing and redundant newlines
  • trailing commas where applicable
  • indentation fixes
  • other things that I found were clearly improvements
stevenroose added 2 commits Oct 8, 2019
- module and use sorting
- remove awkward extra spacing and redundant newlines
- trailing commas where applicable
- indentation fixes
- other things that I found were clearly improvements
@tamasblummer

This comment has been minimized.

Copy link
Member

commented Oct 8, 2019

NACK. Code is handwriting by the original author that we should handle with respect. No one (also means no algo) should re-write code for any other reason than functionality improvement, bug-fix or if its format makes it harder to understand the intent.

@dpc

This comment has been minimized.

Copy link
Contributor

commented Oct 8, 2019

@ tamasblummer . That's a peculiar perspective. I don't think I've seen it before. :)

Obviously code is not a hand-writing. And since the LICENSE states that :

"Certain owners wish to permanently relinquish those rights to a Work for
the purpose of contributing to a commons of creative, cultural and
scientific works ("Commons") that the public can reliably and without fear
of later claims of infringement build upon, modify,"

... pragmatically speaking anyone can do whatever they want with this code. And if the ability to read, modify and work with the given code is increased, it can and should be modified. If the original author intention was to preserve the formatting they should have used a difference license. And most probably find a different medium of creative expression altogether. I'd suggest Haiku poems.

@tamasblummer

This comment has been minimized.

Copy link
Member

commented Oct 8, 2019

I am glad I widened your horizon then. I argued against modifications that are not adding functionality, fixing bugs or significantly enhancing read-ability. If you are a good developer then you care about the format of your code and you are proud of it, it is your way of writing poems. We should have respect of work of others as it is our profession our way of expressing ourselves.

@tamasblummer

This comment has been minimized.

Copy link
Member

commented Oct 8, 2019

My opposition is to re-formatting but not to re-factoring, enhancing, fixing or modifying to re-use in a different context. Besides the above mentioned respect I think re-formatting is disrupting history and outstanding pull requests, is in itself a possible source of errors and can become a source of frustration. I do not want my PRs being rejected because some automated process failed that does not add value.

@jb55

This comment has been minimized.

Copy link

commented Oct 8, 2019

I'm partial to formatters to avoid bikeshedding debates like these, but if we're going to use them we should just use them without making tweaks.

@dpc

This comment has been minimized.

Copy link
Contributor

commented Oct 8, 2019

@tamasblummer

If you are a good developer (...)

"The people sharing my views are good, and not sharing them are bad.". Yeah, right... Ehh...

Obviously, the debate here is going to be a waste of time. Like many other debates about formatting (and many other subjects - usually very minor in practical importance - dogmas loved to be squabbled on by software developers). Spaces or tabs? 2, 4, or 8? 80 or 120? On which line do the ) go?

So, instead, I'd like to point all the interested parties to read 3 tribes of programming, which I find a great take on the root of the problem here.

@tamasblummer here is obviouslya "poet and a mathematician", and I am personally identify with the hacker tribe, consciously trying to be more of a maker.

If you ask me, I'd raze all code with rustfmt unconditionally, even if in certain cases it gives suboptimal results. Just to not have to think about it, or have pointless and endless debated like this one. I don't care about the formatting. I think trying to express stuff through formatting is stupid. "Write a comment if you have something important to say, don't make me waste time trying to guess stuff. I don't have time to decipher your poetry." Formatting doesn't change how the code run, it doesn't make it more or less correct. Standard formatting it is making everyone's life easier on average - because they get used to one standard formatting shared between the whole ecosystem.

@tamasblummer

This comment has been minimized.

Copy link
Member

commented Oct 8, 2019

I expressed my opinion which includes, that a good programmer cares how the code looks like. I see no reason to take that back. Shame on you for turning this discussion into an ad hominem attack going even as far as characterizing me. I continue to let my code speak for me. Prove being a maker by contributing to this project more than 1 line of doc fix, that your stats show.

@tamasblummer

This comment has been minimized.

Copy link
Member

commented Oct 8, 2019

@stevenroose I have an opinion, not a veto right, so if you get two approvals then you merge. I will not be convinced but also not offended if that happens.

@dpc

This comment has been minimized.

Copy link
Contributor

commented Oct 8, 2019

an ad hominem attack going even as far as characterizing me.

@tamasblummer I don't personally consider categorizing as a "poet and mathematician" as anything bad, and it wasn't an attack. I think of all three tribes as a valid points of view / preferences. Coming from different backgrounds, with different focus and goals. It wasn't my intention and I apologize if it came of the wrong way. I just wanted to show how we have completely different perspectives.

I however do dismiss the "good developers", "good software" etc. terms altogether. There is no one and only "good". Some developers love attention to details, some thrive getting most out of the underlying machine, some get a lot of stuff done well and fast, etc. Each tribe would be tempted to consider someone a "good developer" if they share their particular values.

@tamasblummer

This comment has been minimized.

Copy link
Member

commented Oct 8, 2019

I agree that there is no meaningful definition of a "good" developer, but have to call good if a programmer cares of the code's format, what else? You want to re-format because you also consider it good. The dissent is not with the goal but if it is an issue here, how to do and what does it cost. I do not care particular space/tab etc rules only that the format supports understanding. The format carries a kind of meta information that is discarded by the compiler but can be helpful to a human reader. Auto-formatting assumes that there is no value in the format as it is compressible to an algorithm and the residual is just noise. I agree it is mostly noise, some I would call style (handwriting), some valuable hints to reader. I see above mentioned disadvantages in imposing auto-formatting and re-formatting existing code. I think that the code base as is is sufficiently read-able and not particularly noisy, therefore see no upside that I would trade in for those disadvantages.

@stevenroose

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 8, 2019

Let's not escalate this. Having an enforced code style does add value, many recent projects have adopted one and there are now even tools that can make your code conform the style for you.
If you have objections to specific kinds of changes rustfmt makes, I'm very open to changes to the .rustfmt.toml file.

I agree with @jb55 that we should go all the way or nothing. So I'll close this PR in favor of #290.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.