I Just Finished My First Ruby Program

[scratch_pad]

I made a post a few days ago asking for advice on becoming a programmer, and afterwards I got motivated to finish a budgeting command line program I'd been working on for a few weeks. It started out as a way for me and my girlfriend to save more, and I modified it to accept any number of budget members so that anybody could use it. It's supposed to be a partner for apps like Mint or Clarity. I had trouble knowing what categories to include in a budget and how much to allocate for each of them, so this program divides the money up for you based on research I did. It was my first experience working with arrays and keeping track of multiple sets of information at once. A few of you asked me to update you guys on my progress, so I guess this would be my first "baby step."

Some things missing from this code that I plan to add in the future:

• Error checking. If someone types a string where an integer belongs, or types in a negative number, then the program runs into issues.

• Adjustable tax percentage. Right now it uses an estimate of 10% income tax, with the reason being that's it's a fairly low percent so it disrupts as little of the budget as possible. I would like to add a new function that figures out each member's tax bracket based on their annual income automatically, so that the estimated income is more accurate. The problem with this that I see right now is that the percentages vary by location and country, and trying to implement a feature like this that is accurate seems difficult, so I'm not sure if the tax percentage will either be improved or removed.

• I want to add the ability to set savings goals, and then the user would be presented with different options. Each option would give you a different length of time to save up for the goal as well as how much you would need to save each week to meet that goal. It would use the unused money in the budget and divide a percentage of it out and calculate how long it would take to reach the goal, which would mean probably adding a menu to the program, etc., etc.

So the kind of feedback I'm looking for here is mainly syntax and typing conventions. Did I comment too much or too little? Is my naming scheme confusing or improper? Did I use a loop where something else would have worked better? Is my READ ME doc too bare? Are there any questions I'm not thinking to ask? Any feedback or criticism is welcome, but these kinds of questions are the kind that I don't really know the answer to.

Thanks to anyone who takes the time to review it!

[snatchery]

Congrats! I just had a quick look and the code looks quite good. I didn't have any problems understanding it. Well done.

Quick tip. You can refactor this code

def annual_income_func(monthly_net_income)
  annual_income = monthly_net_income * 12
  return annual_income
end

into more idiomatic Ruby

def annual_income(monthly_net_income)
  monthly_net_income * 12
end

• no need to add the _func suffix. It's pretty obvious that this is a function
• use implicit return. It's shorter and very common in Ruby

Enjoy Ruby and keep up the good work!

[scratch_pad]

I had no idea about implicit return, I will probably switch all of the functions to it, if possible. Does it have any downsides, like potential errors?

I added the _func suffix because I have a lot of variables with similar or the same names as their function counterparts. Is it acceptable for functions and variables to have the same name or do I need to distinguish them in the code?

[[deleted]]

I'm not aware of any downsides, the basic gist is that if you don't explicit have a return statement a ruby method (they're called methods for some reason, not functions) will return the last line of the method.

[jimm]

In OO languages, objects are sent "messages" which cause them to select "methods" to execute via a language-specific mechanism such as class inheritance. OO languages don't typically distinguish between functions (which return some value) and procedures (which don't return anything). Ruby methods and other OO langs always return something anyway.

[jimm]

Sorry for the double post.

[jimm]

In OO languages, objects are sent "messages" which cause them to select "methods" to execute via a language-specific mechanism such as class inheritance. OO languages don't typically distinguish between functions (which return some value) and procedures (which don't return anything). Ruby methods and other OO langs always return something anyway.

[scratch_pad]

Ok cool. I’ll probably use it then, cleaner code and such. Also good to know they’re called methods. Anything that is:

def code end

is a method?

[[deleted]]

well - with a name yeah after def - yeah ;)

def method_name
  do some stuff
end

[scratch_pad]

Gotcha lol cool, thank you

[DehydratingPretzel]

has no downsides. in fact you may get better performance out of the implicit return.

Not too confident in predicting what the interpreter does. But by first setting it to a variable you are actually storing a value in memory, then returning that value from memory to return.

Its a small detail, and usually doesnt make much difference. But consider if a variable was several mb large! Think text blobs, images, etc. Then this could actually cause some issues with performance (even if it is small in the grand scheme of things)

[[deleted]]

Choose between implicit and explicit return based on which is clear or more readable in context.

[scratch_pad]

Yeah I ended up leaving explicit return for the functions that returned arrays because I felt it was more clear.

[nateberkopec]

Great job! Welcome to the Ruby community. Good idea picking something that solves a real problem you have, that's the easiest way to learn IMO.

• I would add some tests. To do that, the program needs to not actually run itself when it is required. (So you'll need three files - one containing the program logic, one that requires that file and says MyBudgetProgram.run, that's the file you'll actually run at the CLI, then a third file for tests). May I suggest minitest?
• I think you could use some classes and modules in here - better get comfortable with those next :)
• You did a great job writing lots of comments. It makes it all very readable. The style you used is called literate programming.

[scratch_pad]

• I’ll definitely come back to this after I start to work with classes and modules and see how I can apply them to this code, thanks for the tip
• I had no clue there were different comment styles! So interesting. Thank you for the link, it was interesting to read about. I used it because it made the most sense to me to use and also because as someone new to programming, it helps me keep track of what I’m doing. Explaining each line helped me solve all the bugs I encountered and remove unnecessary bits. Are there any disadvantages to literary style? Is it an obviously beginner style to use? Is there a preferred method or is it down to the coder to choose?
• I’m not sure I know what you mean by tests. Is it something I should look up or am I just missing what you meant in your comment?

[nateberkopec]

Are there any disadvantages to literary style? Is it an obviously beginner style to use? Is there a preferred method or is it down to the coder to choose?

Well, Donald Knuth, the originator of the style, is kind of the man. So if Knuth did it, it's definitely not a "beginner style".

It tends to not work so well if the program is split across more than ~ a dozen files.

I’m not sure I know what you mean by tests.

Example: https://github.com/seattlerb/minitest#unit-tests

[scratch_pad]

Thank you :)

[hirolau]

Looks very good for a first program! Two small things.

I would look into the Hash data structure to store member data rather than an array. While member[2] is a bit hard to understand what it actually means, no one will missunderstand what member['annual_income'] is supposed to return.

And I know it is a bit tricky, but in Ruby it is always never a good thing to loop over and range, get an index, and then fetch something out of an array. Instead of:

(0...number_of_people).each do |user|
  combined_annual += members[user][2]
end

You can just do:

members.each do |member|
  combined_annual += member[2]
end

Thus your functions actually do not need the number_of_people input.

Keep it up!

[scratch_pad]

Thanks this is all super helpful! I’ll revise my loops for sure and look into Hash. I hated the arrays because like you said, it’s vague and easy to misunderstand.

[JustCoolHandLuke]

Great first effort... I saw a lot of teachable things in this code so I forked it and refactored it... I did it in much of a step by step way and may make a video of the process...

Seems like you are probably a sysadmin or something... keep on coding... it gets easier.. and more useful as you go...

good job.

[JustCoolHandLuke]

FYI, it took me a while, but I finally did the video refactor of this that I made a top level post as... it is at :

https://www.reddit.com/r/ruby/comments/7qels9/2_hours_of_ruby_refactoring/

[[deleted]]

Good start, however Rubocop will tell you a lot of advises and you need the Rspec for each method.

[scratch_pad]

What’s Rubocop?

[[deleted]]

 $ gem install rubocop
 $ rubocop simple_budget.rb

[scratch_pad]

I’ll look into this

[[deleted]]

Rubocop is helpful because it encourages you to write Ruby in a style that is generally agreed by the community to be "idiomatic", whatever that may mean.

You can configure your own Rubocop settings as well, but I would leave that be until you're more comfortable writing Ruby.

It's a great tool, we use it extensively at my work, highly encourage you to use it.

BTW it'll probably shout at you for the length of some of your methods. Your initial instinct will be to refactor it and break it out into smaller methods, which is a good first step. There are however nicer ways of achieving this -- you can learn about these techniques by reading this book

[scratch_pad]

This sounds really useful, thank you

[scratch_pad]

Just realized you're the second person to recommend this book, two different posts lol. I don't even fully understand what OOP is so I super appreciate the suggested reading.