Re: Abbreviation code-style requirement.
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 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. > > > > 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 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 abbreviated by plugin (see at the very bottom of > > > this message). I build old version on my machine as well and received > > > the same. It seems that it was there before my changes. Or it might be > > > somehow related to version of IDEA which I used to build the plugin. > > > > > > 2018-12-17 13:35:10,849 [ 21351] ERROR - > > > oring.BaseRefactoringProcessor - Refactorings should not be started > > > inside write action > > > because they start progress inside and any read action from the > > > progress task would cause the deadlock > > > java.lang.Exception > > > at > > > com.intellij.refactoring.BaseRefactoringProcessor.run(BaseRefactoringProcessor.java:560) > > > at > > > com.intellij.refactoring.RefactoringImpl.run(RefactoringImpl.java:73) > > > at > > > org.apache.ignite.idea.inspection.abbrev.IgniteAbbreviationInspection$RenameToFix.rename(IgniteAbbreviationInspection.java:163) > > > at > > > org.apache.ignite.idea.inspection.abbrev.IgniteAbbreviationInspection$RenameToFix.applyFix(IgniteAbbreviationInspection.java:148) > > > at > > > org.apache.ignite.idea.inspection.abbrev.IgniteAbbreviationInspection$RenameToFix.applyFix(IgniteAbbreviationInspection.java:121) > > > at > > > com.intellij.codeInspection.ex.QuickFixWrapper.invoke(QuickFixWrapper.java:75) > > > at > > > com.intellij.codeInsight.intention.impl.IntentionActionWithTextCaching$MyIntentionAction.invoke(IntentionActionWithTextCaching.java:173) > > > at > > > com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.lambda$invokeIntention$3(ShowIntentionActionsHandler.java:202) > > > at > > > com.intellij.openapi.application.WriteAction.run(WriteAction.java:105) > > > at > > > com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.invokeIntention(ShowIntentionActionsHandler.java:204) > > > at > > > com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.lambda$null$1(ShowIntentionActionsHandler.java:179) > > > at > > > com.intellij.openapi.application.TransactionGuardImpl.runSyncTransaction(TransactionGuardImpl.java:88) > > > at > > > com.intellij.openapi.application.TransactionGuardImpl.submitTransactionAndWait(TransactionGuardImpl.java:153) > > > at > > > com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.lambda$chooseActionAndInvoke$2(ShowIntentionActionsHandler.java:178) > > > at > > > com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:139) > > > at > > > com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:97) > > > at > > > com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:87) > > > at > > > com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:73) > > > at > > > com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.chooseActionAndInvoke(ShowIntentionActionsHandler.java:177) > > > at > > > com.intellij.codeInsight.intention.impl.IntentionListStep.lambda$applyAction$0(IntentionListStep.java:118) > > > at > > > com.intellij.openapi.application.TransactionGuardImpl.performUserActivity(TransactionGuardImpl.java:195) > > > at > > > com.intellij.ui.popup.AbstractPopup.lambda$dispose$8(AbstractPopup.java:1417) > > > at com.intellij.util.ui.UIUtil.invokeLaterIfNeeded(UIUtil.java:3097) > > > at > > > com.intellij.ide.IdeEventQueue.ifFocusEventsInTheQueue(IdeEventQueue.java:183) > > > at > > > com.intellij.ide.IdeEventQueue.executeWhenAllFocusEventsLeftTheQueue(IdeEventQueue.java:132) > > > at > > > com.intellij.openapi.wm.impl.FocusManagerImpl.doWhenFocusSettlesDown(FocusManagerImpl.java:190) > > > at > > > com.intellij.openapi.wm.impl.IdeFocusManagerImpl.doWhenFocusSettlesDown(IdeFocusManagerImpl.java:58) > > > at > > >
Re: Abbreviation code-style requirement.
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. > > 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 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 abbreviated by plugin (see at the very bottom of > > this message). I build old version on my machine as well and received > > the same. It seems that it was there before my changes. Or it might be > > somehow related to version of IDEA which I used to build the plugin. > > > > 2018-12-17 13:35:10,849 [ 21351] ERROR - > > oring.BaseRefactoringProcessor - Refactorings should not be started > > inside write action > > because they start progress inside and any read action from the > > progress task would cause the deadlock > > java.lang.Exception > > at > > com.intellij.refactoring.BaseRefactoringProcessor.run(BaseRefactoringProcessor.java:560) > > at > > com.intellij.refactoring.RefactoringImpl.run(RefactoringImpl.java:73) > > at > > org.apache.ignite.idea.inspection.abbrev.IgniteAbbreviationInspection$RenameToFix.rename(IgniteAbbreviationInspection.java:163) > > at > > org.apache.ignite.idea.inspection.abbrev.IgniteAbbreviationInspection$RenameToFix.applyFix(IgniteAbbreviationInspection.java:148) > > at > > org.apache.ignite.idea.inspection.abbrev.IgniteAbbreviationInspection$RenameToFix.applyFix(IgniteAbbreviationInspection.java:121) > > at > > com.intellij.codeInspection.ex.QuickFixWrapper.invoke(QuickFixWrapper.java:75) > > at > > com.intellij.codeInsight.intention.impl.IntentionActionWithTextCaching$MyIntentionAction.invoke(IntentionActionWithTextCaching.java:173) > > at > > com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.lambda$invokeIntention$3(ShowIntentionActionsHandler.java:202) > > at > > com.intellij.openapi.application.WriteAction.run(WriteAction.java:105) > > at > > com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.invokeIntention(ShowIntentionActionsHandler.java:204) > > at > > com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.lambda$null$1(ShowIntentionActionsHandler.java:179) > > at > > com.intellij.openapi.application.TransactionGuardImpl.runSyncTransaction(TransactionGuardImpl.java:88) > > at > > com.intellij.openapi.application.TransactionGuardImpl.submitTransactionAndWait(TransactionGuardImpl.java:153) > > at > > com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.lambda$chooseActionAndInvoke$2(ShowIntentionActionsHandler.java:178) > > at > > com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:139) > > at > > com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:97) > > at > > com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:87) > > at > > com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:73) > > at > > com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.chooseActionAndInvoke(ShowIntentionActionsHandler.java:177) > > at > > com.intellij.codeInsight.intention.impl.IntentionListStep.lambda$applyAction$0(IntentionListStep.java:118) > > at > > com.intellij.openapi.application.TransactionGuardImpl.performUserActivity(TransactionGuardImpl.java:195) > > at > > com.intellij.ui.popup.AbstractPopup.lambda$dispose$8(AbstractPopup.java:1417) > > at com.intellij.util.ui.UIUtil.invokeLaterIfNeeded(UIUtil.java:3097) > > at > > com.intellij.ide.IdeEventQueue.ifFocusEventsInTheQueue(IdeEventQueue.java:183) > > at > > com.intellij.ide.IdeEventQueue.executeWhenAllFocusEventsLeftTheQueue(IdeEventQueue.java:132) > > at > > com.intellij.openapi.wm.impl.FocusManagerImpl.doWhenFocusSettlesDown(FocusManagerImpl.java:190) > > at > > com.intellij.openapi.wm.impl.IdeFocusManagerImpl.doWhenFocusSettlesDown(IdeFocusManagerImpl.java:58) > > at com.intellij.ui.popup.AbstractPopup.dispose(AbstractPopup.java:1411) > > at com.intellij.ui.popup.WizardPopup.dispose(WizardPopup.java:160) > > at > > com.intellij.ui.popup.list.ListPopupImpl.dispose(ListPopupImpl.java:307) > > at com.intellij.openapi.util.Disposer$1.execute(Disposer.java:48) > > at com.intellij.openapi.util.Disposer$1.execute(Disposer.java:44) > > at > >
Re: Abbreviation code-style requirement.
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 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 abbreviated by plugin (see at the very bottom of > this message). I build old version on my machine as well and received > the same. It seems that it was there before my changes. Or it might be > somehow related to version of IDEA which I used to build the plugin. > > 2018-12-17 13:35:10,849 [ 21351] ERROR - > oring.BaseRefactoringProcessor - Refactorings should not be started > inside write action > because they start progress inside and any read action from the > progress task would cause the deadlock > java.lang.Exception > at > com.intellij.refactoring.BaseRefactoringProcessor.run(BaseRefactoringProcessor.java:560) > at > com.intellij.refactoring.RefactoringImpl.run(RefactoringImpl.java:73) > at > org.apache.ignite.idea.inspection.abbrev.IgniteAbbreviationInspection$RenameToFix.rename(IgniteAbbreviationInspection.java:163) > at > org.apache.ignite.idea.inspection.abbrev.IgniteAbbreviationInspection$RenameToFix.applyFix(IgniteAbbreviationInspection.java:148) > at > org.apache.ignite.idea.inspection.abbrev.IgniteAbbreviationInspection$RenameToFix.applyFix(IgniteAbbreviationInspection.java:121) > at > com.intellij.codeInspection.ex.QuickFixWrapper.invoke(QuickFixWrapper.java:75) > at > com.intellij.codeInsight.intention.impl.IntentionActionWithTextCaching$MyIntentionAction.invoke(IntentionActionWithTextCaching.java:173) > at > com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.lambda$invokeIntention$3(ShowIntentionActionsHandler.java:202) > at > com.intellij.openapi.application.WriteAction.run(WriteAction.java:105) > at > com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.invokeIntention(ShowIntentionActionsHandler.java:204) > at > com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.lambda$null$1(ShowIntentionActionsHandler.java:179) > at > com.intellij.openapi.application.TransactionGuardImpl.runSyncTransaction(TransactionGuardImpl.java:88) > at > com.intellij.openapi.application.TransactionGuardImpl.submitTransactionAndWait(TransactionGuardImpl.java:153) > at > com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.lambda$chooseActionAndInvoke$2(ShowIntentionActionsHandler.java:178) > at > com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:139) > at > com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:97) > at > com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:87) > at > com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:73) > at > com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.chooseActionAndInvoke(ShowIntentionActionsHandler.java:177) > at > com.intellij.codeInsight.intention.impl.IntentionListStep.lambda$applyAction$0(IntentionListStep.java:118) > at > com.intellij.openapi.application.TransactionGuardImpl.performUserActivity(TransactionGuardImpl.java:195) > at > com.intellij.ui.popup.AbstractPopup.lambda$dispose$8(AbstractPopup.java:1417) > at com.intellij.util.ui.UIUtil.invokeLaterIfNeeded(UIUtil.java:3097) > at > com.intellij.ide.IdeEventQueue.ifFocusEventsInTheQueue(IdeEventQueue.java:183) > at > com.intellij.ide.IdeEventQueue.executeWhenAllFocusEventsLeftTheQueue(IdeEventQueue.java:132) > at > com.intellij.openapi.wm.impl.FocusManagerImpl.doWhenFocusSettlesDown(FocusManagerImpl.java:190) > at > com.intellij.openapi.wm.impl.IdeFocusManagerImpl.doWhenFocusSettlesDown(IdeFocusManagerImpl.java:58) > at com.intellij.ui.popup.AbstractPopup.dispose(AbstractPopup.java:1411) > at com.intellij.ui.popup.WizardPopup.dispose(WizardPopup.java:160) > at > com.intellij.ui.popup.list.ListPopupImpl.dispose(ListPopupImpl.java:307) > at com.intellij.openapi.util.Disposer$1.execute(Disposer.java:48) > at com.intellij.openapi.util.Disposer$1.execute(Disposer.java:44) > at > com.intellij.openapi.util.objectTree.ObjectNode$1.execute(ObjectNode.java:138) > at > com.intellij.openapi.util.objectTree.ObjectNode$1.execute(ObjectNode.java:107) > at > com.intellij.openapi.util.objectTree.ObjectTree.executeActionWithRecursiveGuard(ObjectTree.java:182) > at > com.intellij.openapi.util.objectTree.ObjectNode.execute(ObjectNode.java:107) > at >
Re: Abbreviation code-style requirement.
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 abbreviated by plugin (see at the very bottom of this message). I build old version on my machine as well and received the same. It seems that it was there before my changes. Or it might be somehow related to version of IDEA which I used to build the plugin. 2018-12-17 13:35:10,849 [ 21351] ERROR - oring.BaseRefactoringProcessor - Refactorings should not be started inside write action because they start progress inside and any read action from the progress task would cause the deadlock java.lang.Exception at com.intellij.refactoring.BaseRefactoringProcessor.run(BaseRefactoringProcessor.java:560) at com.intellij.refactoring.RefactoringImpl.run(RefactoringImpl.java:73) at org.apache.ignite.idea.inspection.abbrev.IgniteAbbreviationInspection$RenameToFix.rename(IgniteAbbreviationInspection.java:163) at org.apache.ignite.idea.inspection.abbrev.IgniteAbbreviationInspection$RenameToFix.applyFix(IgniteAbbreviationInspection.java:148) at org.apache.ignite.idea.inspection.abbrev.IgniteAbbreviationInspection$RenameToFix.applyFix(IgniteAbbreviationInspection.java:121) at com.intellij.codeInspection.ex.QuickFixWrapper.invoke(QuickFixWrapper.java:75) at com.intellij.codeInsight.intention.impl.IntentionActionWithTextCaching$MyIntentionAction.invoke(IntentionActionWithTextCaching.java:173) at com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.lambda$invokeIntention$3(ShowIntentionActionsHandler.java:202) at com.intellij.openapi.application.WriteAction.run(WriteAction.java:105) at com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.invokeIntention(ShowIntentionActionsHandler.java:204) at com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.lambda$null$1(ShowIntentionActionsHandler.java:179) at com.intellij.openapi.application.TransactionGuardImpl.runSyncTransaction(TransactionGuardImpl.java:88) at com.intellij.openapi.application.TransactionGuardImpl.submitTransactionAndWait(TransactionGuardImpl.java:153) at com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.lambda$chooseActionAndInvoke$2(ShowIntentionActionsHandler.java:178) at com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:139) at com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:97) at com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:87) at com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:73) at com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.chooseActionAndInvoke(ShowIntentionActionsHandler.java:177) at com.intellij.codeInsight.intention.impl.IntentionListStep.lambda$applyAction$0(IntentionListStep.java:118) at com.intellij.openapi.application.TransactionGuardImpl.performUserActivity(TransactionGuardImpl.java:195) at com.intellij.ui.popup.AbstractPopup.lambda$dispose$8(AbstractPopup.java:1417) at com.intellij.util.ui.UIUtil.invokeLaterIfNeeded(UIUtil.java:3097) at com.intellij.ide.IdeEventQueue.ifFocusEventsInTheQueue(IdeEventQueue.java:183) at com.intellij.ide.IdeEventQueue.executeWhenAllFocusEventsLeftTheQueue(IdeEventQueue.java:132) at com.intellij.openapi.wm.impl.FocusManagerImpl.doWhenFocusSettlesDown(FocusManagerImpl.java:190) at com.intellij.openapi.wm.impl.IdeFocusManagerImpl.doWhenFocusSettlesDown(IdeFocusManagerImpl.java:58) at com.intellij.ui.popup.AbstractPopup.dispose(AbstractPopup.java:1411) at com.intellij.ui.popup.WizardPopup.dispose(WizardPopup.java:160) at com.intellij.ui.popup.list.ListPopupImpl.dispose(ListPopupImpl.java:307) at com.intellij.openapi.util.Disposer$1.execute(Disposer.java:48) at com.intellij.openapi.util.Disposer$1.execute(Disposer.java:44) at com.intellij.openapi.util.objectTree.ObjectNode$1.execute(ObjectNode.java:138) at com.intellij.openapi.util.objectTree.ObjectNode$1.execute(ObjectNode.java:107) at com.intellij.openapi.util.objectTree.ObjectTree.executeActionWithRecursiveGuard(ObjectTree.java:182) at com.intellij.openapi.util.objectTree.ObjectNode.execute(ObjectNode.java:107) at com.intellij.openapi.util.objectTree.ObjectTree.executeAll(ObjectTree.java:151) at com.intellij.openapi.util.Disposer.dispose(Disposer.java:129) at com.intellij.openapi.util.Disposer.dispose(Disposer.java:125) at com.intellij.ui.popup.WizardPopup.disposeAllParents(WizardPopup.java:263) at com.intellij.ui.popup.list.ListPopupImpl.handleNextStep(ListPopupImpl.java:442) at
Re: Abbreviation code-style requirement.
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 should be added: > 'topologyVersion' -> 'topVer' > 'regularExpression' -> 'regex' Actually, the plugin operates with tokens which are determined assuming camel-case naming style. So, "topologyVersion" will be split to "topology" and "Version" and converted to "topVer" by transforming each token. But we cannot do so with "regularExpression" because there is no rules for "regular" and "expression". And even if we had such it would produce "regEx". Adding a rule "regularExpression=regex" to abbreviation.properties does not lead to desired effect. [1] https://github.com/dspavlov/ignite-abbrev-plugin/pull/2 2018-12-15 12:13 GMT+03:00, Vyacheslav Daradur : > 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 11:17 AM Павлухин Иван wrote: >> >> 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 scala >> support. I will need some time to ensure that I can build it properly. >> >> [1] https://issues.apache.org/jira/browse/IGNITE-10704 >> [2] https://github.com/dspavlov/ignite-abbrev-plugin/pull/2 >> >> 2018-11-02 21:38 GMT+03:00, Dmitriy Pavlov : >> > 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 contributed to the plugin. >> > >> > Some of the authors are not active contributors anymore. So I've stuck >> > with >> > finding a way how to donate. >> > >> > Sincerely, >> > Dmitriy Pavlov >> > >> > пт, 2 нояб. 2018 г. в 21:24, Vyacheslav Daradur : >> > >> >> 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 properties from the plugin. >> >> >> >> On Fri, Nov 2, 2018 at 2:32 PM Vyacheslav Daradur >> >> >> >> wrote: >> >> > >> >> > 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, >> >> > therefore I'm not sure that we really need to do it. >> >> > >> >> > Also, I have another idea we can try to use IDEA inspections and >> >> > it's >> >> > naming conventions rules. >> >> > IDEA inspections are under the project's git already. >> >> > >> >> > [1] >> >> https://www.jetbrains.org/intellij/sdk/docs/basics/architectural_overview/virtual_file.html >> >> > On Fri, Nov 2, 2018 at 1:47 PM Yakov Zhdanov >> >> wrote: >> >> > > >> >> > > 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 >> >> > >> >> > >> >> > >> >> > -- >> >> > Best Regards, Vyacheslav D. >> >> >> >> >> >> >> >> -- >> >> Best Regards, Vyacheslav D. >> >> >> > >> >> >> -- >> Best regards, >> Ivan Pavlukhin > > > > -- > Best Regards, Vyacheslav D. > -- Best regards, Ivan Pavlukhin
Re: Abbreviation code-style requirement.
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 11:17 AM Павлухин Иван wrote: > > 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 scala > support. I will need some time to ensure that I can build it properly. > > [1] https://issues.apache.org/jira/browse/IGNITE-10704 > [2] https://github.com/dspavlov/ignite-abbrev-plugin/pull/2 > > 2018-11-02 21:38 GMT+03:00, Dmitriy Pavlov : > > 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 contributed to the plugin. > > > > Some of the authors are not active contributors anymore. So I've stuck with > > finding a way how to donate. > > > > Sincerely, > > Dmitriy Pavlov > > > > пт, 2 нояб. 2018 г. в 21:24, Vyacheslav Daradur : > > > >> 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 properties from the plugin. > >> > >> On Fri, Nov 2, 2018 at 2:32 PM Vyacheslav Daradur > >> wrote: > >> > > >> > 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, > >> > therefore I'm not sure that we really need to do it. > >> > > >> > Also, I have another idea we can try to use IDEA inspections and it's > >> > naming conventions rules. > >> > IDEA inspections are under the project's git already. > >> > > >> > [1] > >> https://www.jetbrains.org/intellij/sdk/docs/basics/architectural_overview/virtual_file.html > >> > On Fri, Nov 2, 2018 at 1:47 PM Yakov Zhdanov > >> wrote: > >> > > > >> > > 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 > >> > > >> > > >> > > >> > -- > >> > Best Regards, Vyacheslav D. > >> > >> > >> > >> -- > >> Best Regards, Vyacheslav D. > >> > > > > > -- > Best regards, > Ivan Pavlukhin -- Best Regards, Vyacheslav D.
Re: Abbreviation code-style requirement.
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 scala support. I will need some time to ensure that I can build it properly. [1] https://issues.apache.org/jira/browse/IGNITE-10704 [2] https://github.com/dspavlov/ignite-abbrev-plugin/pull/2 2018-11-02 21:38 GMT+03:00, Dmitriy Pavlov : > 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 contributed to the plugin. > > Some of the authors are not active contributors anymore. So I've stuck with > finding a way how to donate. > > Sincerely, > Dmitriy Pavlov > > пт, 2 нояб. 2018 г. в 21:24, Vyacheslav Daradur : > >> 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 properties from the plugin. >> >> On Fri, Nov 2, 2018 at 2:32 PM Vyacheslav Daradur >> wrote: >> > >> > 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, >> > therefore I'm not sure that we really need to do it. >> > >> > Also, I have another idea we can try to use IDEA inspections and it's >> > naming conventions rules. >> > IDEA inspections are under the project's git already. >> > >> > [1] >> https://www.jetbrains.org/intellij/sdk/docs/basics/architectural_overview/virtual_file.html >> > On Fri, Nov 2, 2018 at 1:47 PM Yakov Zhdanov >> wrote: >> > > >> > > 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 >> > >> > >> > >> > -- >> > Best Regards, Vyacheslav D. >> >> >> >> -- >> Best Regards, Vyacheslav D. >> > -- Best regards, Ivan Pavlukhin
Re: Abbreviation code-style requirement.
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 contributed to the plugin. Some of the authors are not active contributors anymore. So I've stuck with finding a way how to donate. Sincerely, Dmitriy Pavlov пт, 2 нояб. 2018 г. в 21:24, Vyacheslav Daradur : > 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 properties from the plugin. > > On Fri, Nov 2, 2018 at 2:32 PM Vyacheslav Daradur > wrote: > > > > 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, > > therefore I'm not sure that we really need to do it. > > > > Also, I have another idea we can try to use IDEA inspections and it's > > naming conventions rules. > > IDEA inspections are under the project's git already. > > > > [1] > https://www.jetbrains.org/intellij/sdk/docs/basics/architectural_overview/virtual_file.html > > On Fri, Nov 2, 2018 at 1:47 PM Yakov Zhdanov > wrote: > > > > > > 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 > > > > > > > > -- > > Best Regards, Vyacheslav D. > > > > -- > Best Regards, Vyacheslav D. >
Re: Abbreviation code-style requirement.
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 properties from the plugin. On Fri, Nov 2, 2018 at 2:32 PM Vyacheslav Daradur wrote: > > 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, > therefore I'm not sure that we really need to do it. > > Also, I have another idea we can try to use IDEA inspections and it's > naming conventions rules. > IDEA inspections are under the project's git already. > > [1] > https://www.jetbrains.org/intellij/sdk/docs/basics/architectural_overview/virtual_file.html > On Fri, Nov 2, 2018 at 1:47 PM Yakov Zhdanov wrote: > > > > 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 > > > > -- > Best Regards, Vyacheslav D. -- Best Regards, Vyacheslav D.
Re: Abbreviation code-style requirement.
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, therefore I'm not sure that we really need to do it. Also, I have another idea we can try to use IDEA inspections and it's naming conventions rules. IDEA inspections are under the project's git already. [1] https://www.jetbrains.org/intellij/sdk/docs/basics/architectural_overview/virtual_file.html On Fri, Nov 2, 2018 at 1:47 PM Yakov Zhdanov wrote: > > 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 -- Best Regards, Vyacheslav D.
Re: Abbreviation code-style requirement.
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
Re: Abbreviation code-style requirement.
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] http://apache-ignite-developers.2346864.n4.nabble.com/Re-Place-Ignite-Abbrev-Plugin-to-ASF-Ignite-supplementary-git-repo-tp32745p32764.html On Fri, Nov 2, 2018 at 12:30 PM Yakov Zhdanov wrote: > > 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 returns with > more contributions then he or she should account all the changes made on > review and, again, come to a point where all project requirements are > staisfied. > > Btw, Vyacheslav, can we have abbreviations.properties in the project under > git and have plugin use it? > > --Yakov -- Best Regards, Vyacheslav D.
Re: Abbreviation code-style requirement.
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 returns with more contributions then he or she should account all the changes made on review and, again, come to a point where all project requirements are staisfied. Btw, Vyacheslav, can we have abbreviations.properties in the project under git and have plugin use it? --Yakov
Re: Abbreviation code-style requirement.
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 On Fri, Nov 2, 2018 at 11:31 AM Павлухин Иван wrote: > > 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 > mandatory today. > > пт, 2 нояб. 2018 г. в 10:58, Dmitriy Pavlov : > > > 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 code, but Ignite has abbreviations seemed to hide this > > meaning". But later I've used to most common abbreviations, like ctx, and > > I always understand that this implies context. > > > > Sincerely, > > Dmitriy Pavlov > > > > пт, 2 нояб. 2018 г. в 10:21, Andrey Kuznetsov : > > > > > 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 нояб. 2018 г. в 10:08, Павлухин Иван : > > > > > > > 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 encourage for new contributions. But if the review > > > > process is not such the contributor can simply give up. > > > > > > > > P.S. In my mind there are quite uncommon code style rules in Ignite > > > > project. But it is definitely not for that topic. I imagine some "New > > > > Contributor Survey". > > > > > > > > чт, 1 нояб. 2018 г. в 18:28, Yakov Zhdanov : > > > > > > > > > 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 confusion and does not hurt readability. > > > > > > > > > > Let's keep using abbreviations and treat them as mandatory > > requirement. > > > > > This is important for keeping our codebase consistent and tidy. > > > > > > > > > > --Yakov > > > > > > > > > > > > > > > > > -- > > > > Best regards, > > > > Ivan Pavlukhin > > > > > > > > > > > > > -- > > > Best regards, > > > Andrey Kuznetsov. > > > > > > > > -- > Best regards, > Ivan Pavlukhin -- Best Regards, Vyacheslav D.
Re: Abbreviation code-style requirement.
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 mandatory today. пт, 2 нояб. 2018 г. в 10:58, Dmitriy Pavlov : > 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 code, but Ignite has abbreviations seemed to hide this > meaning". But later I've used to most common abbreviations, like ctx, and > I always understand that this implies context. > > Sincerely, > Dmitriy Pavlov > > пт, 2 нояб. 2018 г. в 10:21, Andrey Kuznetsov : > > > 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 нояб. 2018 г. в 10:08, Павлухин Иван : > > > > > 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 encourage for new contributions. But if the review > > > process is not such the contributor can simply give up. > > > > > > P.S. In my mind there are quite uncommon code style rules in Ignite > > > project. But it is definitely not for that topic. I imagine some "New > > > Contributor Survey". > > > > > > чт, 1 нояб. 2018 г. в 18:28, Yakov Zhdanov : > > > > > > > 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 confusion and does not hurt readability. > > > > > > > > Let's keep using abbreviations and treat them as mandatory > requirement. > > > > This is important for keeping our codebase consistent and tidy. > > > > > > > > --Yakov > > > > > > > > > > > > > -- > > > Best regards, > > > Ivan Pavlukhin > > > > > > > > > -- > > Best regards, > > Andrey Kuznetsov. > > > -- Best regards, Ivan Pavlukhin
Re: Abbreviation code-style requirement.
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 code, but Ignite has abbreviations seemed to hide this meaning". But later I've used to most common abbreviations, like ctx, and I always understand that this implies context. Sincerely, Dmitriy Pavlov пт, 2 нояб. 2018 г. в 10:21, Andrey Kuznetsov : > 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 нояб. 2018 г. в 10:08, Павлухин Иван : > > > 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 encourage for new contributions. But if the review > > process is not such the contributor can simply give up. > > > > P.S. In my mind there are quite uncommon code style rules in Ignite > > project. But it is definitely not for that topic. I imagine some "New > > Contributor Survey". > > > > чт, 1 нояб. 2018 г. в 18:28, Yakov Zhdanov : > > > > > 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 confusion and does not hurt readability. > > > > > > Let's keep using abbreviations and treat them as mandatory requirement. > > > This is important for keeping our codebase consistent and tidy. > > > > > > --Yakov > > > > > > > > > -- > > Best regards, > > Ivan Pavlukhin > > > > > -- > Best regards, > Andrey Kuznetsov. >
Re: Abbreviation code-style requirement.
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 нояб. 2018 г. в 10:08, Павлухин Иван : > 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 encourage for new contributions. But if the review > process is not such the contributor can simply give up. > > P.S. In my mind there are quite uncommon code style rules in Ignite > project. But it is definitely not for that topic. I imagine some "New > Contributor Survey". > > чт, 1 нояб. 2018 г. в 18:28, Yakov Zhdanov : > > > 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 confusion and does not hurt readability. > > > > Let's keep using abbreviations and treat them as mandatory requirement. > > This is important for keeping our codebase consistent and tidy. > > > > --Yakov > > > > > -- > Best regards, > Ivan Pavlukhin > -- Best regards, Andrey Kuznetsov.
Re: Abbreviation code-style requirement.
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 encourage for new contributions. But if the review process is not such the contributor can simply give up. P.S. In my mind there are quite uncommon code style rules in Ignite project. But it is definitely not for that topic. I imagine some "New Contributor Survey". чт, 1 нояб. 2018 г. в 18:28, Yakov Zhdanov : > 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 confusion and does not hurt readability. > > Let's keep using abbreviations and treat them as mandatory requirement. > This is important for keeping our codebase consistent and tidy. > > --Yakov > -- Best regards, Ivan Pavlukhin
Re: Abbreviation code-style requirement.
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 confusion and does not hurt readability. Let's keep using abbreviations and treat them as mandatory requirement. This is important for keeping our codebase consistent and tidy. --Yakov
Re: Abbreviation code-style requirement.
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 look better to me. Also, futures often denote some asynchronous action, and it could be more expressive to use the name of the action as identifier instead of 'fut'. чт, 1 нояб. 2018 г. в 17:46, Павлухин Иван : > 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? > > And a little follow up. I worry how comfortable is contribution for an > external > contributor with presence of abbreviation rules. I always thought that long > names are common practice in Java world. And our abbreviations might > distract > a typical Java engineer. Does it make any sense? > > [1] > > https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules#AbbreviationRules-VariableAbbreviation > > чт, 1 нояб. 2018 г. в 17:33, Dmitriy Pavlov : > > > 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 non-abbreviated if it is meaningful. > > > > Vyacheslav D., > > > > could you please take a look and would you like to change abbrev plugin > > rules? > > > > Sincerely, > > Dmitriy Pavlov > > > > чт, 1 нояб. 2018 г. в 17:27, Yakov Zhdanov : > > > > > 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 that > are > > > Ignite domain specific. > > > > > > I would also suggest that we treat names mentioned in the table on the > > page > > > as names that are required to be abbreviated. Please take this into > > account > > > when conducting code reviews. > > > > > > Thanks! > > > > > > --Yakov > > > > > > > > -- > Best regards, > Ivan Pavlukhin > -- Best regards, Andrey Kuznetsov.
Re: Abbreviation code-style requirement.
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? And a little follow up. I worry how comfortable is contribution for an external contributor with presence of abbreviation rules. I always thought that long names are common practice in Java world. And our abbreviations might distract a typical Java engineer. Does it make any sense? [1] https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules#AbbreviationRules-VariableAbbreviation чт, 1 нояб. 2018 г. в 17:33, Dmitriy Pavlov : > 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 non-abbreviated if it is meaningful. > > Vyacheslav D., > > could you please take a look and would you like to change abbrev plugin > rules? > > Sincerely, > Dmitriy Pavlov > > чт, 1 нояб. 2018 г. в 17:27, Yakov Zhdanov : > > > 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 that are > > Ignite domain specific. > > > > I would also suggest that we treat names mentioned in the table on the > page > > as names that are required to be abbreviated. Please take this into > account > > when conducting code reviews. > > > > Thanks! > > > > --Yakov > > > -- Best regards, Ivan Pavlukhin
Re: Abbreviation code-style requirement.
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 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 non-abbreviated if it is meaningful. > > Vyacheslav D., > > could you please take a look and would you like to change abbrev plugin rules? > > Sincerely, > Dmitriy Pavlov > > чт, 1 нояб. 2018 г. в 17:27, Yakov Zhdanov : >> >> 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 that are >> Ignite domain specific. >> >> I would also suggest that we treat names mentioned in the table on the page >> as names that are required to be abbreviated. Please take this into account >> when conducting code reviews. >> >> Thanks! >> >> --Yakov -- Best Regards, Vyacheslav D.
Re: Abbreviation code-style requirement.
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 non-abbreviated if it is meaningful. Vyacheslav D., could you please take a look and would you like to change abbrev plugin rules? Sincerely, Dmitriy Pavlov чт, 1 нояб. 2018 г. в 17:27, Yakov Zhdanov : > 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 that are > Ignite domain specific. > > I would also suggest that we treat names mentioned in the table on the page > as names that are required to be abbreviated. Please take this into account > when conducting code reviews. > > Thanks! > > --Yakov >
Re: Abbreviation code-style requirement.
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 that are Ignite domain specific. I would also suggest that we treat names mentioned in the table on the page as names that are required to be abbreviated. Please take this into account when conducting code reviews. Thanks! --Yakov
Re: Abbreviation code-style requirement.
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 different lines of the same method or class will contain abbreviated and non-abbreviated variables, fields and parameters names. This will look ugly. I think nobody thought about source files that are several thousands lines long. Undo abbreviations throughout the entire project is hard work, pretty stupid to do on such huge code base and I am sure will introduce problems and failures on TeamCity. Instead I want to suggest the following: 1. Abbreviations stay mandatory. Making them optional does not make any sense. 2. List of abbreviations should be shortened to up to 20 items and we should leave only those which are common sense. 3. Contributor may also choose to use full words in complex variable names if there is a mix of abbreviated and non-abbreviated words if this helps with readability. I will suggest shorter abbreviations list today or tomorrow and let you know in this thread. Thanks! --Yakov
Re: Abbreviation code-style requirement.
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 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 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 different background have different views. > > The paramount thing here if we can solve such conflicts with a positive > > outcome for all community and for the codebase. > > > > The good friend of mine reminded me some time ago that we all have a > common > > goal here: make the community bigger and this project better. If we > always > > remember that we are connected by a common interest but we admit each > > contributor may have different preferences in coding and probably > different > > opinion. We may build up consensus sharing our arguments if it is really > > needed, or these different opinions/priorities/preferences may co-exist. > > > > In a particular case, if reviewer's concerns are not major, another > > reviewer can agree with your proposal. So it should be always considered > > case-by-case, there is no silver bullet here. > > > > Sincerely, > > Dmitriy Pavlov > > > > вт, 23 окт. 2018 г., 11:32 Maxim Muzafarov : > > > > > 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 `context = ctx`. > > > > > > On Mon, 22 Oct 2018 at 14:05 Павлухин Иван > wrote: > > > > > > > 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 concrete case? > > > > > > > > вс, 21 окт. 2018 г. в 11:34, Dmitriy Pavlov : > > > > > > > > > +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 i,j,cp and etc. are good for > simple > > > > > methods and code blocks; for a fast demonstration of some idea, but > > for > > > > > complex enterprise level software it can hide meaning instead of > > > clearly > > > > > showing it. > > > > > > > > > > As a next step, I would like to propose to contribute an option to > > > > disable > > > > > abbreviation requirements for some cases in ignite-abbrev-plugin. > > > > > > > > > > сб, 20 окт. 2018 г. в 10:47, Zhenya : > > > > > > > > > > > +1 for all proposals. > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Best regards, > > > > Ivan Pavlukhin > > > > > > > -- > > > -- > > > Maxim Muzafarov > > > > > >
Re: Abbreviation code-style requirement.
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 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 different background have different views. > The paramount thing here if we can solve such conflicts with a positive > outcome for all community and for the codebase. > > The good friend of mine reminded me some time ago that we all have a common > goal here: make the community bigger and this project better. If we always > remember that we are connected by a common interest but we admit each > contributor may have different preferences in coding and probably different > opinion. We may build up consensus sharing our arguments if it is really > needed, or these different opinions/priorities/preferences may co-exist. > > In a particular case, if reviewer's concerns are not major, another > reviewer can agree with your proposal. So it should be always considered > case-by-case, there is no silver bullet here. > > Sincerely, > Dmitriy Pavlov > > вт, 23 окт. 2018 г., 11:32 Maxim Muzafarov : > > > 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 `context = ctx`. > > > > On Mon, 22 Oct 2018 at 14:05 Павлухин Иван wrote: > > > > > 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 concrete case? > > > > > > вс, 21 окт. 2018 г. в 11:34, Dmitriy Pavlov : > > > > > > > +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 i,j,cp and etc. are good for simple > > > > methods and code blocks; for a fast demonstration of some idea, but > for > > > > complex enterprise level software it can hide meaning instead of > > clearly > > > > showing it. > > > > > > > > As a next step, I would like to propose to contribute an option to > > > disable > > > > abbreviation requirements for some cases in ignite-abbrev-plugin. > > > > > > > > сб, 20 окт. 2018 г. в 10:47, Zhenya : > > > > > > > > > +1 for all proposals. > > > > > > > > > > > > > > > > > > -- > > > Best regards, > > > Ivan Pavlukhin > > > > > -- > > -- > > Maxim Muzafarov > > >
Re: Abbreviation code-style requirement.
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 different background have different views. The paramount thing here if we can solve such conflicts with a positive outcome for all community and for the codebase. The good friend of mine reminded me some time ago that we all have a common goal here: make the community bigger and this project better. If we always remember that we are connected by a common interest but we admit each contributor may have different preferences in coding and probably different opinion. We may build up consensus sharing our arguments if it is really needed, or these different opinions/priorities/preferences may co-exist. In a particular case, if reviewer's concerns are not major, another reviewer can agree with your proposal. So it should be always considered case-by-case, there is no silver bullet here. Sincerely, Dmitriy Pavlov вт, 23 окт. 2018 г., 11:32 Maxim Muzafarov : > 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 `context = ctx`. > > On Mon, 22 Oct 2018 at 14:05 Павлухин Иван wrote: > > > 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 concrete case? > > > > вс, 21 окт. 2018 г. в 11:34, Dmitriy Pavlov : > > > > > +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 i,j,cp and etc. are good for simple > > > methods and code blocks; for a fast demonstration of some idea, but for > > > complex enterprise level software it can hide meaning instead of > clearly > > > showing it. > > > > > > As a next step, I would like to propose to contribute an option to > > disable > > > abbreviation requirements for some cases in ignite-abbrev-plugin. > > > > > > сб, 20 окт. 2018 г. в 10:47, Zhenya : > > > > > > > +1 for all proposals. > > > > > > > > > > > > > -- > > Best regards, > > Ivan Pavlukhin > > > -- > -- > Maxim Muzafarov >
Re: Abbreviation code-style requirement.
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 `context = ctx`. On Mon, 22 Oct 2018 at 14:05 Павлухин Иван wrote: > 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 concrete case? > > вс, 21 окт. 2018 г. в 11:34, Dmitriy Pavlov : > > > +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 i,j,cp and etc. are good for simple > > methods and code blocks; for a fast demonstration of some idea, but for > > complex enterprise level software it can hide meaning instead of clearly > > showing it. > > > > As a next step, I would like to propose to contribute an option to > disable > > abbreviation requirements for some cases in ignite-abbrev-plugin. > > > > сб, 20 окт. 2018 г. в 10:47, Zhenya : > > > > > +1 for all proposals. > > > > > > > > -- > Best regards, > Ivan Pavlukhin > -- -- Maxim Muzafarov
Re: Abbreviation code-style requirement.
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 concrete case? вс, 21 окт. 2018 г. в 11:34, Dmitriy Pavlov : > +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 i,j,cp and etc. are good for simple > methods and code blocks; for a fast demonstration of some idea, but for > complex enterprise level software it can hide meaning instead of clearly > showing it. > > As a next step, I would like to propose to contribute an option to disable > abbreviation requirements for some cases in ignite-abbrev-plugin. > > сб, 20 окт. 2018 г. в 10:47, Zhenya : > > > +1 for all proposals. > > > -- Best regards, Ivan Pavlukhin
Re: Abbreviation code-style requirement.
+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 i,j,cp and etc. are good for simple methods and code blocks; for a fast demonstration of some idea, but for complex enterprise level software it can hide meaning instead of clearly showing it. As a next step, I would like to propose to contribute an option to disable abbreviation requirements for some cases in ignite-abbrev-plugin. сб, 20 окт. 2018 г. в 10:47, Zhenya : > +1 for all proposals. >
Re: Abbreviation code-style requirement.
+1 for all proposals.
Re: Abbreviation code-style requirement.
+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 Shangareev : > Igniters, > > I want to discuss the appendix of our code-style: > https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules. > > First of all, there is no any mention that it is a mandatory part. > > Secondly, some of them are very unintuitive and even misleading. For > example, cp. In current realization, it could mean not only copy but > checkpoint. Other example, proto... Would you get that it is protocol? > > Thirdly, the recommended plugin highlights even parts of multiword names. > It provokes to used creepy names as > locCpPartitionsInProgress, needCpPartitions and so on. > > So, I want to start a discussion for > 1. revising the list of abbreviations, > 2. stop using them for multi-word names, > 3. and make them not mandatory at all (what it is actually already true, > because of no any mention in the main code-style article). >
Re: Abbreviation code-style requirement.
+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 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 Zinoviev : > > > > > + 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 /counter/, /vertex/, /collection/ and > > etc > > > > > > > > > > > > -- > > > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ > > > > > > > > > -- > > BR, Sergey Antonov > > > > > -- > Best regards, > Ilya >
Re: Abbreviation code-style requirement.
+ 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 Zinoviev : > > > + 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 /counter/, /vertex/, /collection/ and > etc > > > > > > > > -- > > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ > > > > > -- > BR, Sergey Antonov > -- Best regards, Ilya
Re: Abbreviation code-style requirement.
+ 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 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 /counter/, /vertex/, /collection/ and etc > > > > -- > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ > -- BR, Sergey Antonov
Re: Abbreviation code-style requirement.
+ 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 /counter/, /vertex/, /collection/ and etc -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
Re: Abbreviation code-style requirement.
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 names, > 3. and make them not mandatory at all (what it is actually already true, > because of no any mention in the main code-style article). > > -- Alexey Kuznetsov
RE: Abbreviation code-style requirement.
+ 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: dev@ignite.apache.org Subject: Abbreviation code-style requirement. Igniters, I want to discuss the appendix of our code-style: https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules. First of all, there is no any mention that it is a mandatory part. Secondly, some of them are very unintuitive and even misleading. For example, cp. In current realization, it could mean not only copy but checkpoint. Other example, proto... Would you get that it is protocol? Thirdly, the recommended plugin highlights even parts of multiword names. It provokes to used creepy names as locCpPartitionsInProgress, needCpPartitions and so on. So, I want to start a discussion for 1. revising the list of abbreviations, 2. stop using them for multi-word names, 3. and make them not mandatory at all (what it is actually already true, because of no any mention in the main code-style article).
Re: Abbreviation code-style requirement.
+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" : > Igniters, > > I want to discuss the appendix of our code-style: > https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules. > > First of all, there is no any mention that it is a mandatory part. > > Secondly, some of them are very unintuitive and even misleading. For > example, cp. In current realization, it could mean not only copy but > checkpoint. Other example, proto... Would you get that it is protocol? > > Thirdly, the recommended plugin highlights even parts of multiword names. > It provokes to used creepy names as > locCpPartitionsInProgress, needCpPartitions and so on. > > So, I want to start a discussion for > 1. revising the list of abbreviations, > 2. stop using them for multi-word names, > 3. and make them not mandatory at all (what it is actually already true, > because of no any mention in the main code-style article).
Re: Abbreviation code-style requirement.
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 abbreviations just worsen readability of code and don't give any major benefits. вт, 16 окт. 2018 г. в 19:01, Eduard Shangareev : > Igniters, > > I want to discuss the appendix of our code-style: > https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules. > > First of all, there is no any mention that it is a mandatory part. > > Secondly, some of them are very unintuitive and even misleading. For > example, cp. In current realization, it could mean not only copy but > checkpoint. Other example, proto... Would you get that it is protocol? > > Thirdly, the recommended plugin highlights even parts of multiword names. > It provokes to used creepy names as > locCpPartitionsInProgress, needCpPartitions and so on. > > So, I want to start a discussion for > 1. revising the list of abbreviations, > 2. stop using them for multi-word names, > 3. and make them not mandatory at all (what it is actually already true, > because of no any mention in the main code-style article). >
Re: Abbreviation code-style requirement.
+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, collection, callable or a closure, even if I remember the rules by heart. Denis вт, 16 окт. 2018 г. в 19:01, Eduard Shangareev : > Igniters, > > I want to discuss the appendix of our code-style: > https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules. > > First of all, there is no any mention that it is a mandatory part. > > Secondly, some of them are very unintuitive and even misleading. For > example, cp. In current realization, it could mean not only copy but > checkpoint. Other example, proto... Would you get that it is protocol? > > Thirdly, the recommended plugin highlights even parts of multiword names. > It provokes to used creepy names as > locCpPartitionsInProgress, needCpPartitions and so on. > > So, I want to start a discussion for > 1. revising the list of abbreviations, > 2. stop using them for multi-word names, > 3. and make them not mandatory at all (what it is actually already true, > because of no any mention in the main code-style article). >
