I've read the whole booklet and I'm happy to follow most, if not all, the guidelines. Kent Beck's book was influential on this. I have a few remarks, though... Guideline 2.2 Typed variables should mention only existing or loadable types in the system. E.g selectFrom: aDate to: anotherDate and not selectFrom: aBeginningDate to: anEndDate (where Beginning and EndDate are not classes in the system) This affects guideline 2.3 because it says aBinaryBlock and there is no BinaryBlock class. I would also add another guideline here for the use of the 'as' preffix, e.g. asDate, asString, etc. where "as" means a different representation of receiver. E.g. asString is okay, while asShortString is not, because there is no ShortString class. Guideline 2.6 Should be "Number of" or "Count"? E.g. numberOfSomething or somethingCount? I don't like using "of" "with" or similar prepositions to name variables and classes. Guideline 3.2 #beSuprised would be better than #lookSurprised and follows a used convention of using #beSomething, e.g. #beBinary, #beReadOnly, etc. In the Guideline 5.6 the examples are the same. Regards! Esteban A. Maringolo El mié., 2 ene. 2019 a las 2:33, Sean P. DeNigris via Pharo-dev (< pharo-dev@lists.pharo.org>) escribió:

Pharo Smalltalk Developers mailing list wrote

...

Including what the method does, even when the code is fairly simple (OK, not getter / setter methods), is still useful.

Yes, but... there is no free lunch. While there may be a benefit when the code and comment are freshly written and in sync, they are duplication which smells whether code or comment and it is all too easy for the code to be patched without updating the comment. Now that minor speedup turns into a more significant slowdown when a user blindly follows the now-wrong comment. This possibility is made more likely be the fact that a stale comment will not be picked up by the testing framework.

----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html