Having refreshed my memory by rereading that section of the style book - I see
the source of my discomfort... I don’t find the guidelines on parameters very
strong - and I think (like others) I side more with guideline 25 most of the
time where it’s sensible (not just for multiple similar parame
On 11/07/2018 21:21, Sean P. DeNigris wrote:
> Paul DeBruicker wrote
>> It also seems like a "how much milk do you like in your coffee?" choice
>> where the tradeoffs between one vs the other isn't high and the code in
>> action will let you know whether you've got it right.
>
> +1. I also u
Sounds like what I’ve been doing is what others do too - I just wasn’t sure if
my memory had served me well. It was great to be reminded about some of the
subtleties though - hadn’t thought about a/an stopping inst var collisions.
I actually have an original copy of that style book, I was workin
In the day, I learned from Smalltalk with Style:
http://sdmeta.gforge.inria.fr/FreeBooks/WithStyle/SmalltalkWithStyle.pdf
On PDF-page 13 naming starts. On PDF-page 29 parameter names are explained
(but refers back to typed names for example). Naming ends at PDF-page 35. So
quite elaborate explanat
Path".
> Sent: Wednesday, July 11, 2018 at 6:24 PM
> From: "Tim Mackinnon"
> To: "Pharo Users Newsgroup"
> Subject: [Pharo-users] Naming parameters - conventions?
>
> Hi everyone, something I’ve meant to ask over the years, as I’ve seen lots of
>
+100
//
Encrypted email at jgpfers...@protonmail.com
Web: www.objectnets.net and www.objectnets.org
> On Jul 11, 2018, at 18:20, Richard Sargent
> wrote:
>
> Tim Mackinnon wrote
>> Hi everyone, something I’ve meant to ask over the years, as I’ve seen lots
>> of variation an
This payer/payee example is exactly what I was thinking about, and I’ve tended
to do as Dennis suggests and use a type suffix on the name - and wondered if
that was what most people do.
I’ll certainly check what Andreas says on the topic.
Tim
Sent from my iPhone
On 12 Jul 2018, at 06:31, Den
>
> It depends on the current level of abstraction. If you are operating at a
> much higher level, say transfering
> money between two accounts, you would do:
>
#transferMoney from: aPayer to: aPayee
> where both aPayer and aPayee could be anAccountHolder
Why not
#transferMoney from: payerAcc
On Thursday 12 July 2018 03:54 AM, Tim Mackinnon wrote:
I was taught {“a”/“an”}DataType, so it would be:
#name: aString
It depends on the current level of abstraction. At the lowest levels, it
is okay to use basic types like aString since classes (types) define
behavior. If you are operating
Tim Mackinnon wrote
> Hi everyone, something I’ve meant to ask over the years, as I’ve seen lots
> of variation and was taught something else in the day...
>
> What is the suggested way of naming parameters?
>
> I was taught {“a”/“an”}DataType, so it would be:
>
> #name: aString
>
> Which works
Paul DeBruicker wrote
> It also seems like a "how much milk do you like in your coffee?" choice
> where the tradeoffs between one vs the other isn't high and the code in
> action will let you know whether you've got it right.
+1. I also use both. My heuristic is for shorter methods, and methods
I generally go for intention revealing (e.g. fullName) because the class of
the parameter can change arbitrarily. e.g. your aString might become a Name
object that can answer something useful when you know just the first or
family name. But I also mostly write code for my own consumption.
If t
Hi everyone, something I’ve meant to ask over the years, as I’ve seen lots of
variation and was taught something else in the day...
What is the suggested way of naming parameters?
I was taught {“a”/“an”}DataType, so it would be:
#name: aString
Which works ok (although falls apart if you refact
13 matches
Mail list logo
