Val.
> But then you said that common sense doesn't work. Code review IS common sense
> for the most part though.
Code review must catch errors like "No validation in the world prevent me from
typing manually "mess" instead of «msg»"
But, when one reviewer prefers `qry` and another requires `query` it confusing
and stressful.
> 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
Agree. Discussion shows that different opinions exist in community.
I’m relying on rules written in wiki.
If someone wants to change it - please go ahead with vote.
But, silently ignore rules created by ourselves is simply ridiculous.
> So many abbreviations simply make it look cryptic and weird -- this might
> easily confuse a newcomer.
Not agreed, but this seems to be a matter of taste.
> It's also clear why we're struggling. Just one example: we have the rule to
> abbreviate "exception" as "e».
+1 I’m also don’t like these changes :)
Seems we have to do it only for catch block variables.
Will fix.
> 23 июня 2021 г., в 07:24, Ivan Pavlukhina <vololo...@gmail.com> написал(а):
>
> Folks,
>
> I suppose we should rollout voting regarding abbreviations in Ignite 3.
>
> BTW, are you actually aware of any other project defining something similar
> to our abbreviations?
>
> Sent from my iPhone
>
>> On 23 Jun 2021, at 14:53, Nikita Ivanov <nivano...@gmail.com> wrote:
>>
>> 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
>>>>>>
>>>>
>>>>
>>>
