What's worked for countless companies is the combination of the following:
1. Well defined rules (abbreviations, code styles & documentation, code
organization, etc., etc.) for common/frequent use cases.
2. Some basic tooling (wherever possible) plus a strong culture of code
reviews.
3. And... common sense! None of the rules in (1) are axiomatic but rather a
guidance that requires common sense.
Code review culture takes time and organizational discipline to become
effective & productive. Rules alone or some fiat enforcement is unlikely to
work.
--
Nikita Ivanov
On Tue, Jun 22, 2021 at 4:44 PM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> Nikolay,
>
> I'm confused. Konstantin gave you an example of a bad abbreviation that
> cannot be caught by automated validation, and you referred to the code
> review as a solution. But then you said that common sense doesn't work.
> Code review IS common sense for the most part though.
>
> Either way, I'm not against enforced rules per se, but in this case, we are
> clearly struggling to come up with a rule that could work. This and several
> previous discussions show that.
>
> It's also clear why we're struggling. Just one example: we have the rule to
> abbreviate "exception" as "e". This is perfectly fine for the following
> line:
>
> catch (Exception e) {}
>
> But then I see the following in your PR:
>
> boolean isE = false;
>
> I'm ready to argue that this is not an example of good code :) How would
> you propose to fix that? It's really hard to set up generic rules like that
> -- common sense is required.
>
> Also, in general, the impression I get from your PR is that the code
> becomes less readable. So many abbreviations simply make it look cryptic
> and weird -- this might easily confuse a newcomer. And honestly, I have no
> idea how to formalize this.
>
> What is the exact problem that you're trying to solve? Is it that we have a
> rule that is not followed because it's too complicated? In that case, I
> propose to cancel the rule and then try to come up with more general
> guidelines for contributors and reviewers. Again -- common sense is our
> friend here.
>
> WDYT?
>
> -Val
>
> On Tue, Jun 22, 2021 at 12:04 AM Nikolay Izhikov <nizhi...@apache.org>
> wrote:
>
> > Hello, Pavel
> >
> > > But it doesn't mean that now we need to use only full names.
> > > Abbreviations may be used e.g. for local variables with short scope.
> > > Here we must follow common sense and existing practices of effective
> > naming.
> > > It shouldn't be a cargo cult as it is now.
> >
> > But «common sense» has a very different definition for each community
> > member.
> >
> > So, it seems, your proposal will end with different naming styles through
> > codebase.
> > Moreover, one reviewer will require «first» naming style and another
> > «second» because of personal common sense.
> >
> > Personally, I believe strict automatically checked code style rules are
> > better than common sense rules.
> >
> > Meanwhile, please, keep in mind that abbreviation rules is mandatory.
> > And this discussion shown there are many Ignite developers who want to
> > keep it.
> >
> > If someone wants to change or make it optional - please, start a vote.
> >
> >
> > > 21 июня 2021 г., в 21:45, Pavel Kovalenko <jokse...@gmail.com>
> > написал(а):
> > >
> > >>> But do you have a plan what should we do with the subject?
> > >
> > > I think we need to just turn off the required rule for abbreviations
> and
> > > start to write new code without this requirement.
> > > But it doesn't mean that now we need to use only full names.
> > Abbreviations
> > > may be used e.g. for local variables with short scope.
> > > Here we must follow common sense and existing practices of effective
> > > naming. It shouldn't be a cargo cult as it is now.
> > > If there are doubts about naming they should be resolved on a code
> > review.
> > >
> > > And we shouldn't rush to migrate all existing code to names without
> > > existing abbreviations, it doesn't make sense - most core components
> are
> > > modified very rarely now.
> > > If you touch some class and you see that you can make existing naming
> > > better - do it. But starting to renaming everything is the same cargo
> > cult
> > > but only of a different polarity.
> > >
> > >>> Actually it seems to me offtopic
> > >
> > > My concern was in Nikita's words that such rules about abbreviations
> > > simplifies entry of new members that were actually not.
> > > Every such rule actually complicates new member contributions.
> Statistics
> > > above from Ilya just confirms it. Only 4 external valuable contributors
> > for
> > > 6 years of the project. 2 of them have been offline for the last 5
> years.
> > >
> > > пн, 21 июн. 2021 г. в 05:00, Ivan Pavlukhin <vololo...@gmail.com>:
> > >
> > >> Hi Pavel,
> > >>
> > >> Thank you for sharing your thoughts! My personal opinion is very
> > >> similar. But do you have a plan what should we do with the subject? Do
> > >> you suggest to cleanup whole codebase from abbreviations? Or do you
> > >> think that it is fine to keep existing code as is and avoid
> > >> abbreviations for new code? Or something else?
> > >>
> > >>> Who can tell me at least 5 contributors with 10+ commits who are not
> > >> working/worked in GridGain or SberBank? It's sad to hide behind an
> open
> > >> source community that really does not exist.
> > >>
> > >> Actually it seems to me offtopic. But here my opinion is different. It
> > >> is ok to me that the project is mainly driven by aforementioned
> > >> companies. And I would rather care more about ease of single
> > >> contributions. I contributed to other open source projects and did <
> > >> 10 commits to each. Because in daily work generally we use stable
> > >> libraries and can allow ourselves to work only with bugs or
> > >> improvements in open source libraries. And I consider it a way to go
> > >> in open source.
> > >>
> > >> 2021-06-20 14:13 GMT+03:00, Pavel Kovalenko <jokse...@gmail.com>:
> > >>> I think in this discussion there should be a question - why do we
> still
> > >>> need abbreviations for all variables and fields? What problem does it
> > >>> solve?
> > >>> Nobody still clearly answered this question.
> > >>> I saw only 2 arguments to keep abbreviations:
> > >>> 1) Less codebase symbols. I think it is a weak argument. We're not in
> > the
> > >>> 80-90s when there were no modern IDEs with hints and auto-completion.
> > >>> Ideally code should be read just as english text. That really helps
> to
> > >>> understand the code if you see it for the first time. Abbreviations
> > >>> everywhere (except well-known CS terms) don't improve code
> readability.
> > >>> 2) We shouldn't break constitency with old codebase written with
> > enforced
> > >>> abbreviations. Hence the question - why was this rule introduced at
> > >> project
> > >>> startup? Who knows that?
> > >>> I guess most people who decided to introduce this rule left the
> Ignite
> > >>> project.
> > >>>
> > >>>>> Consistency is what makes it easier to contribute to the project
> > >>> Yes it is. But what makes it easier is actually clear architecture,
> > >> simple
> > >>> and convenient abstractions and well-documented code. Ignite has a
> big
> > >> lack
> > >>> of that.
> > >>> For example, look at the transactions or PME codebase. It's darkness
> > and
> > >> no
> > >>> abbreviations for "consistency" will help to understand that code.
> > >>>
> > >>>>> and attract new members
> > >>> Who can tell me at least 5 contributors with 10+ commits who are not
> > >>> working/worked in GridGain or SberBank?
> > >>> It's sad to hide behind an open source community that really does not
> > >>> exist.
> > >>>
> > >>>
> > >>> пт, 18 июн. 2021 г. в 14:21, Anton Vinogradov <a...@apache.org>:
> > >>>
> > >>>>> Agree. I think you can start a discussion and change some abbrevs
> if
> > >>>>> you
> > >>>> wish.
> > >>>>
> > >>>> How about keeping the abbreviation map file inside the Ignite repo?
> > >>>> In this case, you may change the abbreviation by issue/pr covered
> by a
> > >>>> green TC check.
> > >>>>
> > >>>> On Thu, Jun 17, 2021 at 11:36 AM Nikolay Izhikov <
> nizhi...@apache.org
> > >
> > >>>> wrote:
> > >>>>
> > >>>>>> No validation in the world prevent me from typing manually "mess"
> > >>>>> instead of "msg"/«message"
> > >>>>>
> > >>>>> Code review will do.
> > >>>>>
> > >>>>>> btw "svc" is more common imo
> > >>>>>
> > >>>>> Agree. I think you can start a discussion and change some abbrevs
> if
> > >>>>> you
> > >>>>> wish.
> > >>>>>
> > >>>>>
> > >>>>>> 17 июня 2021 г., в 10:23, Ivan Daschinsky <ivanda...@gmail.com>
> > >>>>> написал(а):
> > >>>>>>
> > >>>>>> I'm sorry, but the rule is not strict and, moreover, not clear
> > >> enough
> > >>>> for
> > >>>>>> constans. See here [1]
> > >>>>>> ```
> > >>>>>> Type and method names are usually not abbreviated (except for the
> > >>>>>> well-accepted abbreviations such as EOF, Impl, Fifo, etc.).
> > >>>>>>
> > >>>>>> Abbreviation applies to local variables, method parameters, class
> > >>>> fields
> > >>>>>> and in **some cases public static fileds** (constants) of the
> class.
> > >>>>>> ```
> > >>>>>> But there is not any list that contains these cases. I suppose,
> that
> > >>>>>> constant naming should not be abbreviated.
> > >>>>>> As I see, the most cases of violations, described in initial post,
> > >>>>>> are
> > >>>>>> about constant's namings.
> > >>>>>>
> > >>>>>> I suppose that we should define strict and clear rules about
> > >>>>>> constants
> > >>>>>> naming.
> > >>>>>>
> > >>>>>> [1] --
> > >>>>>
> > https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules
> > >>>>>>
> > >>>>>>
> > >>>>>> чт, 17 июн. 2021 г. в 10:10, Konstantin Orlov <
> kor...@gridgain.com
> > >>> :
> > >>>>>>
> > >>>>>>> Enforced validation doesn't guarantee code consistency. No
> > >>>>>>> validation
> > >>>> in
> > >>>>>>> the world prevent me from typing manually "mess" instead of
> > >>>>> "msg"/"message"
> > >>>>>>> or "svc" instead of "srvc"/"service" (btw "svc" is more common
> > >> imo).
> > >>>>>>>
> > >>>>>>> And the fact that someone name a variable "count" instead of
> "cnt"
> > >>>>> doesn't
> > >>>>>>> make the whole project immature.
> > >>>>>>>
> > >>>>>>> --
> > >>>>>>> Regards,
> > >>>>>>> Konstantin Orlov
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>> On 17 Jun 2021, at 08:34, Ivan Pavlukhin <vololo...@gmail.com>
> > >>>> wrote:
> > >>>>>>>>
> > >>>>>>>> Hi Nikolay,
> > >>>>>>>>
> > >>>>>>>> Thanks, it is rather interesting.
> > >>>>>>>>
> > >>>>>>>> Do we all agree that using different conventions for different
> > >> code
> > >>>>>>>> packages does not break "consistency"? Or did I get something
> > >>>>>>>> wrong?
> > >>>>>>>>
> > >>>>>>>> 2021-06-17 7:12 GMT+03:00, Николай Ижиков <nizhi...@apache.org
> >:
> > >>>>>>>>> Hello, Ivan.
> > >>>>>>>>>
> > >>>>>>>>> We can create checkstyle rule to enforce usage of
> abbreviations.
> > >>>>>>>>> Internal/public code differs by package.
> > >>>>>>>>>
> > >>>>>>>>> PoC of rule [1]
> > >>>>>>>>>
> > >>>>>>>>> [1] https://github.com/apache/ignite/pull/9153
> > >>>>>>>>>
> > >>>>>>>>>> 17 июня 2021 г., в 07:01, Ivan Pavlukhin <vololo...@gmail.com
> >
> > >>>>>>>>>> написал(а):
> > >>>>>>>>>>
> > >>>>>>>>>> Nikita,
> > >>>>>>>>>>
> > >>>>>>>>>> Do you have a plan in your mind how to make Ignite codebase
> > >>>>> consistent?
> > >>>>>>>>>>
> > >>>>>>>>>> AFAIR, we had it intentionally inconsistent for a long time at
> > >>>> least
> > >>>>>>>>>> for one sake: for internal code we used special conventions
> > >> (e.g.
> > >>>>>>>>>> abbreviations, shorten getters) and common Java conventions
> for
> > >>>>> public
> > >>>>>>>>>> API and examples (e.g. no abbreviations and usual getters).
> > >>>>>>>>>>
> > >>>>>>>>>> 2021-06-16 23:37 GMT+03:00, Nikita Ivanov <
> niva...@gridgain.com
> > >>> :
> > >>>>>>>>>>> Consistency is what makes it easier to contribute to the
> > >> project
> > >>>> and
> > >>>>>>>>>>> attract new members. Consistency implies strong, well defined
> > >>>>>>>>>>> and
> > >>>>>>>>>>> universally enforced rules. Just because we have some
> > >>>>>>>>>>> individuals
> > >>>>> who
> > >>>>>>>>>>> are lazy or inexperienced - it does not mean that the entire
> > >>>> project
> > >>>>>>>>>>> should relax the basic-level engineering discipline.
> > >>>>>>>>>>>
> > >>>>>>>>>>> On a personal node - nothing screams "immaturity" louder
> that a
> > >>>> code
> > >>>>>>>>>>> that uses inconsistent naming, commenting, code style &
> > >>>>> organization,
> > >>>>>>>>>>> etc.
> > >>>>>>>>>>> --
> > >>>>>>>>>>> Nikita Ivanov
> > >>>>>>>>>>>
> > >>>>>>>>>>>> On Wed, Jun 16, 2021 at 5:56 AM Andrey Gura <
> ag...@apache.org
> > >>>
> > >>>>>>> wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Hi,
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> I understand that this rule seems too strict or may be
> weird.
> > >>>>>>>>>>>> But
> > >>>>>>>>>>>> removing the rule could lead to review comments like "use
> > >>>>>>>>>>>> future
> > >>>>>>>>>>>> instead of fut". So my proposal is to change rule from
> > >>>>>>>>>>>> "required"
> > >>>>> to
> > >>>>>>>>>>>> "recommended".
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On Wed, Jun 16, 2021 at 2:49 PM Valentin Kulichenko
> > >>>>>>>>>>>> <valentin.kuliche...@gmail.com> wrote:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Konstantin, thanks for chiming in.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> That's exactly my concern. Overformalization is generally
> not
> > >>>>>>>>>>>>> a
> > >>>>> good
> > >>>>>>>>>>>>> thing.
> > >>>>>>>>>>>>> Someone used "mess" to abbreviate "message"? That is surely
> > >>>>>>>>>>>>> not
> > >>>> a
> > >>>>>>> good
> > >>>>>>>>>>>>> coding style, but that's what code reviews are for. I
> believe
> > >>>> that
> > >>>>>>> our
> > >>>>>>>>>>>>> committers are more than capable of identifying such
> issues.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> At the same time, with the current rules, we are *forced*
> to
> > >>>>>>>>>>>>> use
> > >>>>>>>>>>>>> abbreviations like "locAddrGrpMgr", whether we like it or
> > >> not.
> > >>>> All
> > >>>>>>> it
> > >>>>>>>>>>>>> does
> > >>>>>>>>>>>>> is makes it harder to contribute to Ignite, without
> providing
> > >>>> any
> > >>>>>>>>>>>>> clear
> > >>>>>>>>>>>>> value.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> -Val
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> On Thu, Jun 10, 2021 at 9:46 AM Konstantin Orlov <
> > >>>>>>> kor...@gridgain.com>
> > >>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> +1 for making this optional
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Common abbreviation rules is good for sure, but sometimes
> I
> > >>>>> getting
> > >>>>>>>>>>>>>> sick
> > >>>>>>>>>>>>>> of all those locAddrGrpMgr.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>> Regards,
> > >>>>>>>>>>>>>> Konstantin Orlov
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> On 7 Jun 2021, at 14:31, Nikolay Izhikov
> > >>>>>>>>>>>>>>> <nizhi...@apache.org
> > >>>>>
> > >>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Hello, Anton, Alexei.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Thanks for the feedback.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Personally, I’m pretty happy current abbreviation rules
> > >> too.
> > >>>>>>>>>>>>>>> Let see what we can do to make our codebase even more
> > >>>>> consistent.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> 7 июня 2021 г., в 13:23, Alexei Scherbakov <
> > >>>>>>>>>>>>>> alexey.scherbak...@gmail.com> написал(а):
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> -1
> > >>>>>>>>>>>>>>>> Common abbrevs add quality to the code.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> пн, 7 июн. 2021 г. в 12:38, Anton Vinogradov <
> > >> a...@apache.org
> > >>>>> :
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> -1 here.
> > >>>>>>>>>>>>>>>>> We can fix the code and set up the rule.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> This will help to prevent having a weird abbreviation
> > >> like
> > >>>>>>> "mess"
> > >>>>>>>>>>>>>>>>> (from
> > >>>>>>>>>>>>>>>>> "message") or "ign" (from "Ignite").
> > >>>>>>>>>>>>>>>>> Also, the abbreviations list (hardcoded at IDEA plugin)
> > >>>> allows
> > >>>>>>> to
> > >>>>>>>>>>>>>>>>> have
> > >>>>>>>>>>>>>> same
> > >>>>>>>>>>>>>>>>> names across the whole code, this should simplify the
> > >>>> reading.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> On Sat, Jun 5, 2021 at 10:49 PM Valentin Kulichenko <
> > >>>>>>>>>>>>>>>>> valentin.kuliche...@gmail.com> wrote:
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> I also support removing this requirement. It’s not the
> > >>>> first
> > >>>>>>>>>>>>>>>>>> time
> > >>>>>>>>>>>>>> someone
> > >>>>>>>>>>>>>>>>>> brings this up, and so far we haven’t been able to fix
> > >>>>>>>>>>>>>>>>>> it.
> > >>>>> Not
> > >>>>>>>>>>>>>>>>>> worth
> > >>>>>>>>>>>>>> it
> > >>>>>>>>>>>>>>>>> in
> > >>>>>>>>>>>>>>>>>> my view.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> -Val
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> On Sat, Jun 5, 2021 at 11:54 AM Nikolay Izhikov
> > >>>>>>>>>>>>>>>>>> <nizhi...@apache.org>
> > >>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> Hello, guys.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> Thanks for the feedback.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> Dmitry,
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> Manual rule enforcement saves a couple of symbols in
> > >>>>>>>>>>>>>>>>>>>> code
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> I’m talking about automatic check.
> > >>>>>>>>>>>>>>>>>>> We can implement it easily.
> > >>>>>>>>>>>>>>>>>>> So, if we decide to keep this rule all we need is to
> > >> fix
> > >>>>>>>>>>>>>>>>>>> current
> > >>>>>>>>>>>>>>>>>>> violations (several thousand!).
> > >>>>>>>>>>>>>>>>>>> After it, checkstyle will automatically enforce this
> > >>>>>>>>>>>>>>>>>>> rule.
> > >>>>>>>>>>>>>>>>>>> As you may know, currently, any PR checked according
> to
> > >>>> our
> > >>>>>>>>>>>>>> checkstyle
> > >>>>>>>>>>>>>>>>>>> rules.
> > >>>>>>>>>>>>>>>>>>> Please, take a look at little green check sign after
> PR
> > >>>>> name.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> 5 июня 2021 г., в 00:57, Dmitry Pavlov <
> > >>>> dpav...@apache.org
> > >>>>>>
> > >>>>>>>>>>>>>>>>>> написал(а):
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> +1 for removal. Cnt and count both seem to be fine.
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> Manual rule enforcement saves a couple of symbols in
> > >>>> code,
> > >>>>>>> but
> > >>>>>>>>>>>>>>>>> requires
> > >>>>>>>>>>>>>>>>>>> some time from both contributor and reviewer.
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> Sincerely,
> > >>>>>>>>>>>>>>>>>>>> Dmitriy Pavlov
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> On 2021/06/04 19:18:37, Pavel Tupitsyn <
> > >>>>> ptupit...@apache.org
> > >>>>>>>>
> > >>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>> In my opinion, we should remove this rule.
> > >>>>>>>>>>>>>>>>>>>>> Looks like a waste of time. freq or frequency, cnt
> or
> > >>>>> count,
> > >>>>>>>>>>>>>>>>>>>>> it is
> > >>>>>>>>>>>>>>>>>> fine
> > >>>>>>>>>>>>>>>>>>>>> either way.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> On Fri, Jun 4, 2021 at 7:39 PM Nikolay Izhikov <
> > >>>>>>>>>>>>>> nizhi...@apache.org
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> Hello, Igniters.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> Right now, we have the rule to use some predefined
> > >>>>>>>>>>>>>>>>>>>>>> list
> > >>>>> of
> > >>>>>>>>>>>>>>>>>> abbrevation
> > >>>>>>>>>>>>>>>>>>> for
> > >>>>>>>>>>>>>>>>>>>>>> variable names [1].
> > >>>>>>>>>>>>>>>>>>>>>> Some of the reviewers ask to follow this rule
> > >>>>>>>>>>>>>>>>>>>>>> strictly.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> It is required to use abbreviated form for code
> > >>>>>>>>>>>>>>>>>>>>>>> consistency.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> I tried to implement this rule in form of
> checkstyle
> > >>>>> check
> > >>>>>>>>>>>>>>>>>>>>>> [2] and
> > >>>>>>>>>>>>>>>>> it
> > >>>>>>>>>>>>>>>>>>>>>> seems like many of use doesn’t follow this
> > >>>>>>>>>>>>>>>>>>>>>> requirement.
> > >>>>>>>>>>>>>>>>>>>>>> My check found 4124 violation in core module.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> Should we make this rule optional in documentation
> > >> or
> > >>>>>>> should
> > >>>>>>>>>>>>>>>>>>>>>> we
> > >>>>>>>>>>>>>>>>>> remove
> > >>>>>>>>>>>>>>>>>>> it
> > >>>>>>>>>>>>>>>>>>>>>> completely?
> > >>>>>>>>>>>>>>>>>>>>>> Or should someone proceed and fix all the
> > >> violations?
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> WDYT?
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> Example of output:
> > >>>>>>>>>>>>>>>>>>>>>> ```
> > >>>>>>>>>>>>>>>>>>>>>> [ERROR]
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>>
> > >>
> >
> /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsWithTtlTest.java:94:
> > >>>>>>>>>>>>>>>>>>>>>> Abbrevation should be used for
> > >>>>>>>>>>>>>>>>>>>>>> CACHE_NAME_LOCAL_ATOMIC!
> > >>>>>>>>>>>>>>>>>>>>>> Please,
> > >>>>>>>>>>>>>> use
> > >>>>>>>>>>>>>>>>>>> loc,
> > >>>>>>>>>>>>>>>>>>>>>> instead of LOCAL [IgniteAbbrevationsRule]
> > >>>>>>>>>>>>>>>>>>>>>> [ERROR]
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>>
> > >>
> >
> /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsWithTtlTest.java:97:
> > >>>>>>>>>>>>>>>>>>>>>> Abbrevation should be used for
> CACHE_NAME_LOCAL_TX!
> > >>>>> Please,
> > >>>>>>>>>>>>>>>>>>>>>> use
> > >>>>>>>>>>>>>>>>> loc,
> > >>>>>>>>>>>>>>>>>>>>>> instead of LOCAL [IgniteAbbrevationsRule]
> > >>>>>>>>>>>>>>>>>>>>>> [ERROR]
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>>
> > >>
> >
> /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsWithTtlTest.java:264:
> > >>>>>>>>>>>>>>>>>>>>>> Abbrevation should be used for checkpointManager!
> > >>>> Please,
> > >>>>>>> use
> > >>>>>>>>>>>>>>>>>>>>>> mgr,
> > >>>>>>>>>>>>>>>>>>> instead
> > >>>>>>>>>>>>>>>>>>>>>> of Manager [IgniteAbbrevationsRule]
> > >>>>>>>>>>>>>>>>>>>>>> [ERROR]
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>>
> > >>
> >
> /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsPartitionPreloadTest.java:63:
> > >>>>>>>>>>>>>>>>>>>>>> Abbrevation should be used for DEFAULT_REGION!
> > >>>>>>>>>>>>>>>>>>>>>> Please,
> > >>>>> use
> > >>>>>>>>>>>>>>>>>>>>>> dflt,
> > >>>>>>>>>>>>>>>>>>> instead of
> > >>>>>>>>>>>>>>>>>>>>>> DEFAULT [IgniteAbbrevationsRule]
> > >>>>>>>>>>>>>>>>>>>>>> [ERROR]
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>>
> > >>
> >
> /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsWholeClusterRestartTest.java:47:
> > >>>>>>>>>>>>>>>>>>>>>> Abbrevation should be used for ENTRIES_COUNT!
> > >> Please,
> > >>>> use
> > >>>>>>>>>>>>>>>>>>>>>> cnt,
> > >>>>>>>>>>>>>>>>>> instead
> > >>>>>>>>>>>>>>>>>>> of
> > >>>>>>>>>>>>>>>>>>>>>> COUNT [IgniteAbbrevationsRule]
> > >>>>>>>>>>>>>>>>>>>>>> [ERROR]
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>>
> > >>
> >
> /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsRebalancingOnNotStableTopologyTest.java:49:
> > >>>>>>>>>>>>>>>>>>>>>> Abbrevation should be used for
> CHECKPOINT_FREQUENCY!
> > >>>>>>> Please,
> > >>>>>>>>>>>>>>>>>>>>>> use
> > >>>>>>>>>>>>>>>>>> freq,
> > >>>>>>>>>>>>>>>>>>>>>> instead of FREQUENCY [IgniteAbbrevationsRule]
> > >>>>>>>>>>>>>>>>>>>>>> [ERROR]
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>>
> > >>
> >
> /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsTransactionsHangTest.java:75:
> > >>>>>>>>>>>>>>>>>>>>>> Abbrevation should be used for MAX_KEY_COUNT!
> > >> Please,
> > >>>> use
> > >>>>>>>>>>>>>>>>>>>>>> cnt,
> > >>>>>>>>>>>>>>>>>> instead
> > >>>>>>>>>>>>>>>>>>> of
> > >>>>>>>>>>>>>>>>>>>>>> COUNT [IgniteAbbrevationsRule]
> > >>>>>>>>>>>>>>>>>>>>>> [ERROR]
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>>
> > >>
> >
> /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsTransactionsHangTest.java:78:
> > >>>>>>>>>>>>>>>>>>>>>> Abbrevation should be used for
> CHECKPOINT_FREQUENCY!
> > >>>>>>> Please,
> > >>>>>>>>>>>>>>>>>>>>>> use
> > >>>>>>>>>>>>>>>>>> freq,
> > >>>>>>>>>>>>>>>>>>>>>> instead of FREQUENCY [IgniteAbbrevationsRule]
> > >>>>>>>>>>>>>>>>>>>>>> [ERROR]
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>>
> > >>
> >
> /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/SlowHistoricalRebalanceSmallHistoryTest.java:57:
> > >>>>>>>>>>>>>>>>>>>>>> Abbrevation should be used for
> SUPPLY_MESSAGE_LATCH!
> > >>>>>>> Please,
> > >>>>>>>>>>>>>>>>>>>>>> use
> > >>>>>>>>>>>>>>>>> msg,
> > >>>>>>>>>>>>>>>>>>>>>> instead of MESSAGE [IgniteAbbrevationsRule]
> > >>>>>>>>>>>>>>>>>>>>>> [ERROR]
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>>
> > >>
> >
> /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgniteLogicalRecoveryTest.java:74:
> > >>>>>>>>>>>>>>>>>>>>>> Abbrevation should be used for SHARED_GROUP_NAME!
> > >>>> Please,
> > >>>>>>> use
> > >>>>>>>>>>>>>>>>>>>>>> grp,
> > >>>>>>>>>>>>>>>>>>> instead
> > >>>>>>>>>>>>>>>>>>>>>> of GROUP [IgniteAbbrevationsRule]
> > >>>>>>>>>>>>>>>>>>>>>> [ERROR]
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>>
> > >>
> >
> /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgniteLogicalRecoveryTest.java:200:
> > >>>>>>>>>>>>>>>>>>>>>> Abbrevation should be used for cacheLoader!
> Please,
> > >>>>>>>>>>>>>>>>>>>>>> use
> > >>>>>>> ldr,
> > >>>>>>>>>>>>>>>>> instead
> > >>>>>>>>>>>>>>>>>> of
> > >>>>>>>>>>>>>>>>>>>>>> Loader [IgniteAbbrevationsRule]
> > >>>>>>>>>>>>>>>>>>>>>> ```
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> [1]
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>>
> > >>
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules#AbbreviationRules-VariableAbbreviation
> > >>>>>>>>>>>>>>>>>>>>>> [2] https://github.com/apache/ignite/pull/9153
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Best regards,
> > >>>>>>>>>>>>>>>> Alexei Scherbakov
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> --
> > >>>>>>>>>>
> > >>>>>>>>>> Best regards,
> > >>>>>>>>>> Ivan Pavlukhin
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> --
> > >>>>>>>>
> > >>>>>>>> Best regards,
> > >>>>>>>> Ivan Pavlukhin
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>> --
> > >>>>>> Sincerely yours, Ivan Daschinskiy
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> > >>
> > >> --
> > >>
> > >> Best regards,
> > >> Ivan Pavlukhin
> > >>
> >
> >
>
