

Tips for naming variables - albertoG
http://makinggoodsoftware.com/2009/05/04/71-tips-for-naming-variables/

======
mojuba

      void swap(int* x, int* y)
        { int t = *x; *x = *y; *y = t; }
    

Small blocks with very obvious code are perfectly Ok to have short variable
names in. All other rules in this post can be criticized as easily.

Hence, rule #8: forget about the previous rules, just be a smart coder.

~~~
sethg
Indeed, I think one very useful rule for naming variables is "the length of
the name should be proportional to the scope". If you're iterating through a
list of objects representing unfilled orders, it's OK to do this:

    
    
      for uo in unfilledOrdersIterator():
          oid = uo.id
          status = uo.status
          email = uo.customer.email
          sendEmail(email, "Your order %s is in status %s" % (oid, status))
    

But if there's a 200-line method that does all sorts of other things with a
single unfilled order, then calling the order "uo" is probably a bad idea.

~~~
pp
Shouldn't there NOT be 200-line methods in the first place?

~~~
nuclear_eclipse
There are some cases where 200-line methods are perfectly acceptable, when
breaking the logic into smaller functions only complicates the understanding
and development of the algorithm. Not everything can be broken into multiple
elegant 10-line functions without obfuscating the purpose or control flow.

~~~
sethg
One thing I've occasionally done to tame large functions is this:

    
    
      def frobWidget(widget):
          def frobCog(cog):
              ## stuff involving both cog and widget
          ## stuff involving widget
          frobbedCogs = [frobCog(cog) for cog in widget]
          ## more stuff involving widget and frobbedCogs
    

If frobCog were broken out into a separate function, then it would have to
take widget as an argument, and if frobCog is never actually called from
anywhere other than within frobWidget, then such separation makes the code
harder to understand. Keeping the definition internal lets me take advantage
of lexical scope; I can refer to widget within the definition of frobCog.

~~~
mojuba
In the example you showed I'd probably do the same, true, but I think there is
no evil in passing widget as an argument.

In general, there's nothing wrong with functions that take everything they use
as arguments. This is kind of functional programming (or a good part of it):
every function is as independent as possible, which makes them easier to
debug, easier to understand, and safer in terms of bugs. Functions that deal
with data from outer scopes risk being less readable and less reliable.

------
babo
Stopped reading here: "Good example: daysFromDateRangeStartToEnd".

~~~
albertoG
Hi babo,

you are absolutely right with your observation, that variable name its just a
bad example, I have just edited the post and I have changed its name to
daysDateRange.

Thanks for your feedback

~~~
pwim
Neither your original daysFromDateRangeStartToEnd nor daysDateRange seem to
capture what it is supposed to represent. Perhaps if it was seen in context,
it would be understandable, but by itself I do not think it is a good example.

------
Deestan
> Example. If your customer just considers “order” an “order” that has been
> approved, don’t call “order” to a non approved one in your code, call it
> “nonApprovedOrder”.

Doesn't this violate his rule #5?

~~~
albertoG
Hi Deestann, good catch, I should have stressed that these are guidelines not
rules, what I meant is if possible use positive logic, but it fits better the
negative, use the negative one.

Thanks for the comment

------
ashleyw
Ideally should be using short methods, so what's wrong with using generic
names?

------
Daniel_Newby
"Don´t use negative logic for your variable names."

Obviously written by a software weenie who lives far, far away from the actual
hardware. ;-) (Digital logic often uses active-low signals for good electrical
reasons. And some purely historic reasons: do memory chips actually _need_ to
power up in the activated state?)

~~~
wlievens
What what what?

~~~
Daniel_Newby
Many circuits work with Boolean values that are true in the 0 state, and false
in the 1 state: negative logic. That had better be reflected in the variable
names.

