-
Notifications
You must be signed in to change notification settings - Fork 340
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
Use gofmt/goimports #203
Comments
I was mostly a C++ developer before building Duplicacy so you may find many c++ styles in the code. I would like to hear other people's opinions. |
I'm primarily a Java developer who uses Eclipse, which has the ability to customize how your code is formatted. That both helps standardize coding conventions on a project (which is a very good thing) and allows every project to set its own crazy standard that you then have to retrain your brain to when you switch to a new project. Tabs vs. spaces is a religious war that no one will win (though everyone will agree that you shouldn't mix them for indentation purposes), and the fact that Go uses them instead of spaces means that you have to switch your brain when you switch between languages. BUT having all Go programs do things the same would mean that at least you don't have to retrain your brain when you switch from one Go-based project to another, and it should theoretically mean that tools that mechanically change the code should work more reliably. So since that seems to be the community-accepted standard way to do things, I'm in favor of making that the standard. If it's fast enough (and the codebase is small enough), I'd propose linting the code on each push to the GitHub repo (can that be done?) to reject any PR merge that doesn't conform. If that's a bridge too far, then at least have a CI server such as Jenkins lint the codebase asynchronously after every commit and treat lint failures as a test failure. |
Yeah @tbain98, this is what i was thinking as well: even though i don't like it (im a spaces guy), i think that we (this project) should use the official go formatting standard. |
Just checked in 923cd0a. |
Goimports should do a little bit more than gofmt, hence i think it should be all right. |
Just checked now and i see that something still isn't all right. The only problem is line endings: i see that in some files clrf is used (windows) but at least in my case, goimports changes that to lf (linux). i am using go 1.9, with all the libraries new. I am raising this problem since it is possible that files will be modified in git, and actually nothing will be shown in the diff. (both in source tree and in intellij files are shown as modified, but the diff shows no differences) |
Some of the comments on golang/go#16355 seems to indicate that Git may play a role in choosing cr vs crlf, but I don't have time now to dig deeper.
|
Now I need to figure out how to configure vi so that I use tabs instead of spaces for go files... :) |
Or configure it to invoke goimports when you tell it to save.
|
A commit hook would be better for that I would think. |
I don't see any Windows newlines. I mainly edit source files on maxOS with Visual Studio Code. |
In that case it may be something wrong in my git/go/intellij/i don't even know config? |
@TheBestPessimist Can you provide the names of a couple files where you're seeing inconsistent line terminators? |
@tbain98 i am unsure what happened last time. maybe i changed my settings in my ide, or something else. right now, with a new download of the repository the line endings look ok. With this said, i think that @gilbertchen can close this issue whenever you find fit. |
Hello,
Firstly i hope i won't sound rude, this is more of a question/enhancement than a bug.
I have finally started working on #123 and #124 and i am using intellij idea as my ide.
I see that in your code you are not using gofmt and goimports, and because of this my file(s) look rather different compared to yours.
For example, one particular change is that gofmt uses tabs (i think that's horrible and whoever thought of this should feel really bad) instead of spaces.
My question is: would you like to use gofmt and goimports on your code, and then push a new version, just with these changes, or should we just figure out and stick to your indentation rules?
The text was updated successfully, but these errors were encountered: