Refactor/Code: Clarify/Improve Naming, Namespaces per feedback. about bc-ruby HOT 1 OPEN

My thoughts so far.

Your variable/method names are not very Ruby-ish. The Ruby community prefers snake_case rather than camelCase, except for class/module names.
I have to get with the program. I hate underscores because they take two fingers to type and I have typing issues.

I'm also not super clear on why you keep prefixing argument names with a (ie aMap).
Always in prior works, it was incredibly confusing not to easily distinguish arguments (a*) variables vs locals. I see now though that with the modern focus on very short methods, it's really not necessary. For my background it was hard to read even the short ones at first because I didn't grok the convention, but now I probably am fine with that. Even my own methods I did a pretty good job of keeping them short - that was one of my focus points. So again, get with the program is the solution.

You have "if x != nil" in a few places. It's more idiomatic to just use truthy/falsy values directly, so that'd be "if !x" or "unless x" instead.
OK!

Your namespacing feels a bit redundant. Why Money::Money and Store::Store, &c? What was the purpose of enclosing those like that?
I was confused about this. I felt I should make separate [modules/files] but I didn't see any reason to name them differently from their only class. Do you think I should have omitted the namespace entirely?

Methods like validAsProductID feel like an indication that you might want a ProjectId object that knows how to validate itself.
I struggled with validation! I couldn't see how people 'normally' do it. So do you recommend the constructor include validation? So something like myMember = aMember if valid(aMember)?

Ruby methods return the value of their last line, so using an explicit "return" in the last line is generally not done.
Makes sense.

I like that you're storing money as pennies.
I did that on my own and then also read elsewhere it is a good way. I heard a DBA horror story about money rounding so it's sort of in my consciousness.

I'm really confused by all the commented out stuff, like in https://github.com/AnneTheAgile/bc-ruby/blob/master/specZFut/zRspec_let_spec.rb . Best to just delete it and trust that it's in git if you need it.
My FUD is that once I delete things, Github search will no longer find it, right? In fact, I just have to remember it somehow. This is one of my worst issues. I think I have a smaller mental crow than many devs, so one solution in the past was keeping alot of stuff. That doesn't really work long term though since it's painful to go through lots of things. I haven't quite figured it out. Possibly I could use the ticketing system and open and immediately cancel a ticket that indicates, for example a design path not chosen? Maybe I should write to myself about this and think out my goals more.

I made the ticket for myself.
#11

I fixed my labels to be more what I like as well. I see life in a ticket system as CRUD (add, change/delete, doc/report) plus cancelled items, whose type is irrelevant, and questionable items, whose fix type is unclear. Do you find these labels helpful?
0 add-enhance
3 chg-refactor
3 doc-reports
1 fix-bug
0 question
0 z-cancelled

thank you!
Anne

from bc-ruby.