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
>>>>>
>>>
>>>
>>
