Request of all plugin developers - Verbose Logging

Discussion in 'Plugin Development' started by TnT, May 13, 2012.

Thread Status:
Not open for further replies.
  1. Offline


    If you're showing someone learning to code, obviously you should show him the right way from the start. Keep that = True crap in the pseudocode.
    CypherX and Sagacious_Zed like this.
  2. Offline


    Guys, stop arguing. It does not matter, even slightly !
  3. Offline


    Well, it may be true that they are making for fuss than it's worth. But the truth has to be said, it is better to break these bad/unneccessary habits while you can. It is only for the better. I would prefer people to use if(isBooleanVar) as opposed to if(isBooleanVar == true).

    One, it looks far neater. It's less to read. Don't say it would confuse anyone because once you get used to it (which doesn't take long might i add) then it is as quick and easier if not more so than using the == true.

    It's less code ... need i say more. If you needed multiple boolean statements in one then it is far more preferable e.g
    if(booleanVarOne == true && booleanVarTwo == true && booleanVarThree != true && booleanVarFour == false)

    when you could do
    if(booleanVarOne && booleanVarTwo && !booleanVarThree && !booleanVarFour) ... see how much less space that took

    I know that was a slight exaggeration but the point stays the same.
    Btw i did not aim this mini rant at you, but just to get my thoughts across on the matter.
    desht, Sagacious_Zed and ZachBora like this.
  4. Offline


    Saying that it is the right way implies that the long way is inherently wrong - Do you have any arguments for not using it beyond readability in certain situations? It's a personal choice, just like if you place your {'s on a new line (I do, it makes for more readable code in my opinion).
  5. Offline

    Sagacious_Zed Bukkit Docs

    using the == operator creates an extra operation that may or may not be optimized out, its all together more work to mean the same thing, Not that anyone cares in this day and age of wasted cycles and extra typing.

    EDIT: violates a simplicity principle, just like you get points off on a math test for writing 2/4 instead of 1/2.
  6. Offline


  7. Offline


  8. I'll add this to all my plugins in the next few weeks!
  9. Offline


    I'll agree that boolean/!boolean beats boolean == true/boolean != true/boolean == false any day of the week, but to be fair basically all of us accidentally toss out a == from time to time when we're concentrating on more important parts of code.

    Just fix them when you see them and don't make a big deal about it ;P.
    BobbyD441 likes this.
  10. Offline


    Unless you use == accidentally to compare strings without noticing it :p
  11. Offline


    My plugin only outputs 4 lines when starting, but I guess most people ignore that anyways. I'm in!
  12. Offline


    Logical code framework is essential yes, but, learn for the sake of learning, improve for the sake of improving. Who cares how you use it. Unless you just want to make everything as less efficient as possible. The one problem with this thread isn't the littering of 'bad examples' but rather the essence of opinions of code. You code your way others will code their way. Leave it that way. You can't change everything. Or should I say YourCode != OthersCode.
    BobbyD441 likes this.
  13. Offline


    Considering how much of a difference it makes people seem to care an awful lot.

    I could understand if it was something that you could actually measure the performance impact of or was logically wrong, but this is basically a formatting issue.
  14. Offline


    Exactly, people are just being ignorant in my opinion. Assuming their coding structure is better than everyone elses.
  15. Offline

    Sagacious_Zed Bukkit Docs

    Pretty much every math class you will be in will assert that 2/4 is the wrong answer for 1/2, and y = 3x + 4 + 3 should never be given as an answer over y = 3x + 7. Boolean expressions are no exception.
  16. Offline


    Multiverse has agreed to do this now as well.
  17. Offline


    I thought Multiverse went inactive. Good news :D
  18. Offline


    They are very active still.
  19. Offline


    Am I looking in the wrong place for the plugins ? They still use BukkitDev ? I guess I should start following on GitHub.
  20. Offline


    A great suggestion was making this available in the bukkit.yml file. Plugins can tie into this log level to display finer levels of logging, if they should so choose. However, when off, nothing is displayed.

    Vote it up to get it noticed.
  21. Offline


    There we go, voted for it (i hope). I do hope they implement this.
  22. Offline


    Sorry I am a bit confused. My plugins use more than one line to display information on if things loaded correctly. What if there is a problem? I know other ways to notify the admin of the problem, but i want to do it in console as well. I do understand the annoyance (Believe me, I do.) but some of the stuff is important.
  23. Offline

    Sagacious_Zed Bukkit Docs

    If there is a problem report the problem, If nothing went wrong, say nothing.
  24. Offline


    They still have some kind of weekly build or daily build. That's how I use it on my server :)
  25. Offline


    Will do in the next version of my plugin and all future plugins. Might add a status command as well so admins can check what would normally appear in the log
  26. Offline


    Good idea!
  27. make an plugin disable itself and give an error at the log when it cant startup, else print an message that its able to startup, that how I do it mostly
  28. If it's stuff that *needs* to be checked on sure, but most people won't bother and they'll just complain the plugin doesn't work without checking that, it's best you print all your plugin issues, but not print anything if it's working fine.
  29. Offline


    Bukkit should NOT add a "verbose-logging" entry to its bukkit.yml. This entirely defeats the purpose of even using java.util.logging.Logger -- we might as well just use System.out.println and create our own functions that check if verbosity is enabled or not (which is essentially what we must do if we add a verbose-logging config entry to Bukkit or our plugins)

    If anything, Bukkit should be implementing configuration values to define which log levels are written to server.log and the console. Better yet, allow us to define log files for different log levels so for example we can put all SEVERE log messages to X.log and everything else (modular configuration of course) to another. In the Java logger, these log levels are defined as: SEVERE, WARNING, INFO, CONFIG, FINE, FINER, and FINEST. You can see a better explanation of each level's intended use here.

    By default, I imagine Bukkit would want to show SEVERE, WARNING, INFO levels (possibly forcing severe to be always on), allowing server admins to specify how much they want to see. Of course, this means that plugin authors must abide by these but most plugins will already use INFO so you would probably want to move startup messages to CONFIG as most plugins just output effects that will be made from config-related changes. This change is as simple as changing to logger.config

    What you are proposing not only moves us backwards but also forces everyone into a situation where they must comply with checking if verbosity is enabled by adding code on our end or be labelled as "that plugin." We're already using Java's own logger, so why are we trying to work around it?

    edit: above is unedited, but just wanted to also mention that I realize the BUKKIT-1715 addresses log levels, it would just be nicer if it were more modular. As well, adding a log level after we're pressing "verbose-logging" so much means it's already too late if we start using "verbose-logging", as everyone will think it's no different.
  30. Offline


    I'm gonna ninja in here and advertise a project we've been working on:

    Minecraft log parsing at its (not very) best :)
Thread Status:
Not open for further replies.

Share This Page