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 (< [email protected]>) 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 > >
