I would first experiment to run the critics only on the modified code, not the full package :)
Then you can have a pretty accurate feedback Ben On Oct 6, 2013, at 4:26 PM, b...@openinworld.com wrote: > Benjamin wrote: >> >> What I would like (and will probably give a try soon) is to run some critics >> automatically before committing a MC package :) >> That's how it's done in WebStorm by example, and I love this feature >> >> Ben >> > That sounds cool. Without having used Code Critics yet (I've just discovered > the menu option the Nautilus package pane), I am interested if your idea > would that include a diff with the critics from the previous commit? While > it a full list of critic-isms is be good prompt to reduce the list to zero, > also useful would be knowing if any new critic-isms had been introduced in > this commit. This might help at least maintain the status-quo without having > to solve all existing critic-isms at once, to avoid new ones being lost > amongst a potentially large existing list. > > cheers -ben >> On Oct 6, 2013, at 2:19 PM, b...@openinworld.com wrote: >> >> >>> Stéphane Ducasse wrote: >>> >>>> Hi >>>> I'm really happy because >>>> "New Critic Rule: Nobody should directly send #methodDict" is the way >>>> to go. We should document the system design using automatic rules! >>>> Excellent! >>>> >>>> Stef >>>> >>>> >>>> >>> So you could also have "Critic Rule: Should not implement system method." >>> Like PharoLauncher got stuck having implemented class-side method #layout >>> [1] >>> >>> btw, apart from having a separate critics browser, are the any plans to >>> integrate it further into the system, perhaps as: >>> * a Critics Panel in Nautilus in the same position as the Comments Panel, >>> or perhaps appended to the Comment. * contextual highlighting >>> >>> cheers -ben >>> >>> [1] https://pharo.fogbugz.com/default.asp?11783 >>> >>> >>> >>> >> >> >> >
