FAQ
Fellow gophers,

looking over the current code base of the standard library (assisted by
golint), I noticed a number of style inconsistencies, mainly variable
names using snake_case instead of CamelCase¹, Id vs ID but also a number
of other "issues".

A fair amount of it occurs in tests, but there's also a substantial
amount in actual library code, for example in archive/tar and
archive/zip.

My question is whether the team sees any merit in sending CLs that
correct these inconsistencies, or whether such CLs would be considered
noise with little value.

Also, if such changes were to be sent, should they be separated into one
CL per package, or condensed into few CLs that address one issue for all
packages at once?


I'm not looking for a discussion, just a simple "sure, go ahead" or "no thank
you."

¹: I am not referring to certain constants (e.g. s_IFREG) or obviously
useful uses of snake_case (e.g. init4_224)

Dominik Honnef

--

---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Rob Pike at Jun 13, 2013 at 3:24 pm
    Without examples or a suggestion of the scope, it's hard to answer
    such a blanket request. Cleaning up the code is good, though. How
    about sending out a small trial fixing up one package, and we'll see
    what that tells us?

    -rob

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dominik Honnef at Jun 13, 2013 at 4:35 pm
    Rob Pike writes:
    --text follows this line--
    Without examples or a suggestion of the scope, it's hard to answer
    such a blanket request. Cleaning up the code is good, though. How
    about sending out a small trial fixing up one package, and we'll see
    what that tells us?

    -rob

    I went ahead and cleaned up both compress/flate and flag in the
    envisioned scope. compress/flate benefitted from it more than flag; the
    changes to flag are trivial.

    compress/flate: https://codereview.appspot.com/10268043/
    flag: https://codereview.appspot.com/10269043

    On the grand scale I'd like to eventually go through all of the standard
    library and find general quirks to clarity and idioms.

    flag is a good example for the lower extreme, while compress/flate would
    depict the average amount of changes per package.


    I haven't mailed out the CLs yet, only presenting them in this thread.

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedJun 13, '13 at 2:51p
activeJun 13, '13 at 4:35p
posts3
users2
websitegolang.org

2 users in discussion

Dominik Honnef: 2 posts Rob Pike: 1 post

People

Translate

site design / logo © 2022 Grokbase