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.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
On Oct 6, 2013, at 2:19 PM, btc@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! StefSo 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