Hi,
I uploaded updated version of the plugin to community wiki [1].
[1] https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules
пн, 17 дек. 2018 г. в 19:47, Павлухин Иван :
>
> Dmirity,
>
> Thank you! Permissions works for me.
>
> I will spend a while using a newly built plugin on
Dmirity,
Thank you! Permissions works for me.
I will spend a while using a newly built plugin on my machine and then
will publish it to the wiki and write back.
пн, 17 дек. 2018 г. в 15:40, Dmitriy Pavlov :
>
> Hi Ivan,
>
> I've merged your PR and added permissions to the wiki, please check.
>
Hi Ivan,
I've merged your PR and added permissions to the wiki, please check.
I still feel we need to migrate code to ASF repo. I will try to do
something for that.
Sincerely,
Dmitriy Pavlov
пн, 17 дек. 2018 г. в 13:44, Павлухин Иван :
> Hi,
>
> I did some investigation regarding scala
Hi,
I did some investigation regarding scala support and it seems that
version used today (3.0.0) was build without scala support. If nobody
minds I suggest to build a new version without scala as well.
Also there is a thing that bothers me a little. IDEA throws exception
in log when a name is
Vyacheslav,
> PR looks good to me in general, but I've noticed a possible typo in
> the PR and Wiki:
> 'lable' -> 'label'
Good catch! I updated a PR [1]. Could someone fix it on wiki or give
me rights to edit wiki? (my login is "pavlukhin")
> Also, according to the wiki, the following rules
Ivan, thank you!
PR looks good to me in general, but I've noticed a possible typo in
the PR and Wiki:
'lable' -> 'label'
Also, according to the wiki, the following rules should be added:
'topologyVersion' -> 'topVer'
'regularExpression' -> 'regex'
Am I miss something?
On Sat, Dec 15, 2018 at
Hi Dmitriy, Vyacheslav,
I created a ticket [1] and PR [2] for updating a list of abbreviations
used by the plugin. The changes in the plugin itself looks trivial.
But some extra build and publish steps are required (see the ticket).
Also if I understand it correctly plugin should be build with
Hi Vyacheslav,
I'm sorry I almost gave up with this donation
http://apache-ignite-developers.2346864.n4.nabble.com/Re-Place-Ignite-Abbrev-Plugin-to-ASF-Ignite-supplementary-git-repo-tp32745p32764.html
because
we need someone to sign a software grant agreement, but there were several
people who
I've double checked, we are really able to use IDEA inspection's to
inspect abbreviations by inspection's structure search and replace
templates.
It rather not intuitive and requires complex regex patterns.
Also, at first sight, it shouldn't be difficult to work with the
project's local
I like your idea about auto updates.
In this case, abbr-plugin should be improved to check and download
updates from external URI or local repo.
Looks like it could be implemented using Intellij's SDK virtual file [1].
But as I can see that abbreviations list update is the very rare case,
No, I meant under Ignite's git so any change to resource file arrives with
project workspace updates and gets automatically picked up by plugin.
Makes sense?
--Yakov
Yes, it's under git already in Dmitry Pavlov's GitHub account [1].
AFAIK donation to ASF is in progress [2]. (Dmitry Pavlov, please,
correct me if I'm wrong)
[1]
https://github.com/dspavlov/ignite-abbrev-plugin/blob/master/src/abbreviation.properties
[2]
Agree with Vyacheslav - reviewers can either fix the issues or ask to fix
them. After several PRs new contributors will get used with project
requirements.
As far as one time contributions, they are usually pretty simple and should
not take any significant time to fix. If one time contirbutor
I've faced such practice.
Very first my contribution, when I have not been familiar with style
guidelines, Yakov Zhdanov kindly fixed code style issues himself.
I think it depends on a reviewer:
- in one case reviewer can fix issues independently
- in other case ask a contributor to solve them
Andrey, Dmitry,
If we have a practice of formatting a code before merge by committer
then it is already much better. But do we have such a practice?
As for me personally. I have not felt much discomfort with abbreviations.
I already used them extensively. Even "cctx", "ccfg" which are not
Hi Ivan,
provided that committer has installed ignite-abbrev-plugin it is not a big
deal to abbreviate common words before a merge.
I had the same impression about abbreviations when I came to the project:
"all other development world tends to expose as much meaning as it is
humanly possible in
Ivan, I agree with you: some our code style rules are really uncommon.
As for one-time contributions, if somebody decides to make a contribution
to some project, it's ok to adopt that project rules. Moreover, reviewing
committer can silently fix minor code style issues himself upon merge.
пт, 2
Andrey, Yakov,
Actually my concert is more about one-time contributions. I imagine
the following. Someone finds a bug a decides to contribute a fix.
I think it is quite common scenario in Open Source.
He creates a PR and awaits a review. I think that a smooth and fast
review process will
Ivan I removed "lic" from the list. Thanks for catch!
Agree with Andrey. After several code reviews newcomers will get used to
abbreviations.
Andrey, try searching for "fut" and make sure to have "Word" checked. You
will see plenty of usages. "f" is also ok for future in case it does not
bring
Ivan, I think it's harder to read others' code than write new code, so well
known abbreviations may be helpful. As for writing, it's a matter of habit,
and also abbeviation plugin is a good aid.
I like current abbreviation list, except 'fut'. Never saw this before
Ignite. 'f' or 'future' could
Hi Yakov and all,
Recently I went through abbreviations list [1] to find items which are not
clear
for me. After the list was shortened by Yakov and others most of them have
gone.
But pay attention to "lic -> license". I cannot find usages of it in Ignite
codebase?
Could it be removed as well?
Hi Dmitry, it's easy to update abbrev plugin rules.
Once nobody has objections about updated abbreviations list I'll do it.
On Thu, Nov 1, 2018 at 5:33 PM Dmitriy Pavlov wrote:
>
> Hi Yakov, thank you for your efforts.
>
> I think no one is suggesting de-abbreviate, it would be no-sense work to
Hi Yakov, thank you for your efforts.
I think no one is suggesting de-abbreviate, it would be no-sense work to
do. I think the initial reason to start this discussion was the case when
abbreviation seemed as hiding meaning, and multi-word. I'm glad we agree
multiword complex variables may be
Igniters,
I have shortened the list of abbreviation rules and edited our wiki page -
https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules.
Thanks to Vladimir Ozerov and Alexey Goncharuk for their useful feedback.
My idea was to leave only "common sense" abbreviations and those
Guys, I am sorry I missed this discussion. Apparently, abbreviations use is
far from being the biggest problem in the project. I think everyone agrees
here.
I vote for leaving abbreviations mandatory, and would be strongly against
making them optional since we will endup in situation when
Hi Eduard, feel free to share your wiki ID, I could set up an edit
permissions.
ср, 24 окт. 2018 г. в 14:18, Eduard Shangareev :
> Igniters,
> thank you for your feedback.
>
> I haven't seen any arguments against making abbreviation optional and not
> mandatory.
> So, could we update our wiki
Igniters,
thank you for your feedback.
I haven't seen any arguments against making abbreviation optional and not
mandatory.
So, could we update our wiki with code style to reflect our new vision on
abbreviations?
On Tue, Oct 23, 2018 at 2:01 PM Dmitriy Pavlov
wrote:
> Hi Ivan
>
> if by
Hi Ivan
if by conflict we mean arguing and fighting it is definitely should be
avoided, it never helps the community.
But if we mean different opinions on details (variable namings, method
structure, etc), such different views are unavoidable and I find it is
perfectly ok that people with
Igniters,
I think it's easy to disable the code style abbreviation plugin option by
switching off
the checkbox on - File | Settings | Inspections | Apache Ignite | Incorrect
Java abbreviation usage.
+1 to make abbreviation not mandatory, but I'd like to keep it for common
variable names like
Hi all,
I also think that abbreviations should not be mandatory (point 3).
But what I am worrying about is a conflict resolution between a patch
submitter and a reviewer.
How to come to an agreement when one side is strictly for and another side
is strictly against
using abbreviations in some
+1 for proposal 3.
1. I'm not sure we need to revisit all abbreviations as a lot of people get
used to it.
2. I'm not sure multiword is always need to be fully named, sometimes it
may be ok to abbreviate.
3. But I agree with abbreviations should not be mandatory.
Abbreviated and short names like
+1 for all proposals.
+1.
I think we should use longer names when possible, even for a small pieces
of code, cause this makes code self descriptive. I can agree that for
really small and obvious methods we can use short words like "context", but
not confusing abbreviated one.
вт, 16 окт. 2018 г., 19:01 Eduard
+1 to
> leave abbreviations for common words with single meaning. For example,
group -> grp, transaction -> tx, context -> ctx.
And optional for the multi-words.
ср, 17 окт. 2018 г. в 14:54, Ilya Lantukh :
> + 1 from me to make abbreviations optional.
>
> On Wed, Oct 17, 2018 at 1:00 PM Sergey
+ 1 from me to make abbreviations optional.
On Wed, Oct 17, 2018 at 1:00 PM Sergey Antonov
wrote:
> + 1
>
> But, I think that we must leave abbreviations for common words with single
> meaning. For example, group -> grp, transaction -> tx, context -> ctx.
>
> ср, 17 окт. 2018 г. в 12:46, Alexey
+ 1
But, I think that we must leave abbreviations for common words with single
meaning. For example, group -> grp, transaction -> tx, context -> ctx.
ср, 17 окт. 2018 г. в 12:46, Alexey Zinoviev :
> + 1
> I dislike the current list of abbreviations. It gives me a pain to support
> code with
+ 1
I dislike the current list of abbreviations. It gives me a pain to support
code with unclear variables naming, also I agree that we should avoid crazy
Java camel long naming like
FactoryBuildingCrazyAffinityCallerForComibingInSpace but instead that we
make shorter clear concepts like
Ed, and All.
I'm "+1" for "revising the list of abbreviations,"
How about to have only 5-10 nice (proven) abbreviations and let developers
to name variables using common sense?
So, I want to start a discussion for
> 1. revising the list of abbreviations,
> 2. stop using them for multi-word
+ for all three.
I got used to seeing `cctx` and `ccfg` all over the place, but I remember the
sorrow of seeing all of that the first time.
I guess it’s nothing but a Stockholm syndrome now and I’m willing to cure
myself :)
Stan
From: Eduard Shangareev
Sent: 16 октября 2018 г. 19:01
To:
+1
Eduard, I totally agree with you that it is misleading. I believe
developer/reviewer able to choose convenient name in each particular case by
themself. In my opinion abbreviation should be not mandatory.
--
Best regards,
Anton Kalashnikov
16.10.2018, 19:01, "Eduard Shangareev" :
>
Eduard,
+1 for that topic.
I don't see any reasons to use these abbreviations at all and vote to
deprecate them.
If anybody can explain why we still need them (less number of letters in
variable names is not an argument) we can discuss and revisit the current
list.
>From my side of view, these
+1
I'm for long and descriptive names over short and counterintuitive.
I think, abbreviations shouldn't be mandatory, as they often obscure the
meaning of used names.
One-letter abbreviations should be removed from the list at all.
When I see a variable *c*, I can't tell, whether it's a char,
42 matches
Mail list logo
