Just my two cents : Have preference for not capitalizing all the characters in abbrevications, so BranchSqlOperator is totally fine with me. It's also easier to type (less pressing on Caps key!), and also Might be easier to read and check. +1 on that.
- Howard On Fri, Feb 4, 2022 at 1:20 PM Ferruzzi, Dennis <ferru...@amazon.com.invalid> wrote: > In December Elad organized a community project ( > https://github.com/apache/airflow/issues/20139) which included > un-PEP-8-ing the Amazon provider package, the all-caps acronyms you see > there are/should all be deprecated. > > That said, I do find it easier to read as `BranchSqlOperator`, so > that format would be my vote if I had one. > > > *From:* Jarek Potiuk <ja...@potiuk.com> > *Sent:* Friday, February 4, 2022 7:16 AM > *To:* dev@airflow.apache.org > *Cc:* Felix Uellendall > *Subject:* RE: [EXTERNAL] [DISCUSS] how to name classes with > abbreviations? > > > *CAUTION*: This email originated from outside of the organization. Do not > click links or open attachments unless you can confirm the sender and know > the content is safe. > > 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 >> >> >> >> >> >> >> >>
