Feedback on my Github
- Thread starter FireFlower
- Start date
- Status
PebbleHost
High performance, consistent uptime and fast support. Minecraft hosting that just works.
1. Don't add IDE related files to git
2. Instead of this, use maven or gradle to configure how project should be build.
3. Name your class by plugin name, not just Main
4. Use consistent formatting style, don't mix spaces and tabs, every IDE have a shortcut to auto-format code based on your configured style
5. In java names of variables, fields and methods should be in lowerCamelCase not CamelCase
6. hasPermission already checks for op etc, also plugin/yml can be used to configure default behavior for op players.
7. https://github.com/Exeton/CommandSh...fire/MortalShortener/CommandListener.java#L16 this probably should only reaplce full words?
8. packages should be only lowercase
And more...
2. Instead of this, use maven or gradle to configure how project should be build.
3. Name your class by plugin name, not just Main
4. Use consistent formatting style, don't mix spaces and tabs, every IDE have a shortcut to auto-format code based on your configured style
5. In java names of variables, fields and methods should be in lowerCamelCase not CamelCase
6. hasPermission already checks for op etc, also plugin/yml can be used to configure default behavior for op players.
7. https://github.com/Exeton/CommandSh...fire/MortalShortener/CommandListener.java#L16 this probably should only reaplce full words?
8. packages should be only lowercase
And more...
In some cases, you may want to share these. More information here.
There is no reason to share such files in public projects, as people use different IDEs, and you should be sure that your project can be imported without any additional data other than maven/gradle
People include this file only if they want to create shared working environment, mostly for legacy and shitty projects. And sometimes for too complicated projects with many native stuff, but rare and often also results of bad project
Last edited:
No profile picture.
No bio.
No descriptions on repos.
No READMEs.
No contributing guides.
No style to follow.
You don't contribute to other opensource projects.
Not following anyone or starring projects, building your network.
Shit commit messages.
Useless forks (you forked a project yet no commits).
2/10.
No bio.
No descriptions on repos.
No READMEs.
No contributing guides.
No style to follow.
You don't contribute to other opensource projects.
Not following anyone or starring projects, building your network.
Shit commit messages.
Useless forks (you forked a project yet no commits).
2/10.
Last edited:
Not true. This is a common method of sharing code styling and other project-related settings.
Example of a public project committing IDE files. https://github.com/google/graphicsfuzz
Last edited:
Why isn't it?
I'm using it as an example, what is your point? You haven't seen it used before, therefore it's invalid?
GotoFinal Thanks for the feedback. I'll work on improving my naming conventions. Also wasn't aware of the isOp check when checking permission.
Deleted User Thanks for the link to IntelliJ, I probably won't change the project structure because that's a bit of work, and I feel it's a minor detail.
MarkFreak What commit messages do you think I could improve? And why does it matter whether I star / follow?
Deleted User Thanks for the link to IntelliJ, I probably won't change the project structure because that's a bit of work, and I feel it's a minor detail.
MarkFreak What commit messages do you think I could improve? And why does it matter whether I star / follow?
The name of your project "CommandShortner" contains a typo. Do you mean "CommandShortener"?
No automatic tests.
README should start with a general overview to give the naive reader some orientation:
"This project is a Bukkit plugin for the Minecraft server. ..."
More detailed information about how to build, install and configure your plugin is also important.
Gradle or Maven based build systems are able to generate IDE specific files.
Such a build system is helping other devs (with other IDEs) who want to contribute to your project.
It's easier to integrate with CI systems for test automation.
Follow Java package naming conventions by using your reversed Internet domain name.
[DOUBLEPOST=1539428130][/DOUBLEPOST]
I have never paid attention to it. But you are right: this is very important if an open-source project wants to get in touch with the community.
Thank you!
No automatic tests.
README should start with a general overview to give the naive reader some orientation:
"This project is a Bukkit plugin for the Minecraft server. ..."
More detailed information about how to build, install and configure your plugin is also important.
Gradle or Maven based build systems are able to generate IDE specific files.
Such a build system is helping other devs (with other IDEs) who want to contribute to your project.
It's easier to integrate with CI systems for test automation.
Follow Java package naming conventions by using your reversed Internet domain name.
[DOUBLEPOST=1539428130][/DOUBLEPOST]
I have never paid attention to it. But you are right: this is very important if an open-source project wants to get in touch with the community.
Thank you!
Last edited:
Thanks, I'll work on adding those changes.
- Status
