Surprisingly, as opinionated as I often am, I am happy to follow whatever rules others agree with here :).
Even if we agree that "either is ok" and we mix them and keep them inconsistent and even if someone we do this and sometimes that. I simply do not see huge value in standardizing this. Why? Following the "human language" that you mentioned, Bas (as I see it at least), the right answer is "it depends". IMHO in human language the capitalization rules for acronyms vary and are full of exceptions and depend on context. Some acronyms are better CAPITALIZED but for some it's perfectly ok to be CapWorded and which one is better "felt" depends on who you are, what background and experience you have, and whether English is your native language. For example, for me TCP is clearly very bad when CapWorded as 'Tcp' , but Http is far more pleasant than HTTP. And (just to anticipate arguments) it's not only about the length, it's also about some past experiences and how many of each I've been intimately familiar with (i.e. how many documents and code I read and written on each mostly). So just to protect my sanity I developed a blind spot and for me either is OK and even if we have no consistency, I simply don't care :). That also saves a lot of mental effort to discuss and think about it, to be perfectly honest. So I will follow whatever rule others feel strong about. J. On Fri, Feb 4, 2022 at 11:07 AM Bas Harenslak <b...@astronomer.io.invalid> wrote: > Thanks for opening this discussion, hopefully we can improve consistency, > regardless the outcome. > > +1 for capitalizing abbreviations. IMO since abbreviations are written > capitalised in human language, using the same convention in code gives > clarity. > > Bas > > On 4 Feb 2022, at 07:26, Felix Uellendall <felue...@pm.me.INVALID> wrote: > > Sorry in this case I would be NOT in favor of pep8. I misread it. > > -feluelle > > > Sent from ProtonMail for iOS > > > On Fri, Feb 4, 2022 at 07:22, Felix Uellendall <felue...@pm.me.INVALID> > wrote: > > I am in favor of pep8 guidelines. I think it makes sense to clearly see > separation between words/tokens. For me uppercase is harder to read and I > don’t like getting screamed at. As long as there is documentation, this can > be written there correctly as you can split it like normal words (by > spaces). > > -feluelle > > > Sent from ProtonMail for iOS > > > On Fri, Feb 4, 2022 at 01:46, Daniel Standish < > daniel.stand...@astronomer.io.INVALID> wrote: > > How should we name, for example, an operator such as `BranchSQLOperator`? > > This operator used to be called `BranchSqlOperator` but at some point in > the past was renamed. > > Meanwhile we have SparkSqlOperator which uses the other convention. > > And we have `EmrBaseSensor`, and `EMRContainerOperator` coexisting. > > On this SO post > <https://stackoverflow.com/questions/2853531/how-do-you-pep-8-name-a-class-whose-name-is-an-acronym> > you can find argument on both sides of the debate. > > On one side you have a quote from PEP-8: > > Note: When using abbreviations in CapWords, capitalize all the letters of >> the abbreviation. Thus HTTPServerError is better than HttpServerError. >> > > On the other side you have an example like this: > > class NASAJPL: > > > vs > >> class NasaJPL > > vs > >> class NasaJpl > > > By one argument, option 3 is most readable because the "tokens" are > clearly separated (i.e. nasa and JPL) -- and certainly in some IDEs this > can be a great benefit. > > And perhaps the argument for option 2 is you say "nasa" and "J-P-L" not > "nasa" and "jipple" -- in contrast with SQL where reasonable people say > "sequel" and not "ess queue ell". > > This comes up pretty regularly, and I think we ought to make a decision > and do some pre-commit work to enforce (with an exception list a la > spelling-wordlist.txt) the decision. > > So, please consider debate kicked off, and have at it. > > Thanks > > > > > > > >
