EPT
On November 24 2015 11:36 patrick321 wrote:
The OP's post was clever but fecalfeast's was art. The form perfectly embellished the content. And his topical name was the cherry on top of the cow pie.
Critiquing his code here is like stopping a singer to correct his lyrics.
The OP's post was clever but fecalfeast's was art. The form perfectly embellished the content. And his topical name was the cherry on top of the cow pie.
Critiquing his code here is like stopping a singer to correct his lyrics.
I actually appreciate the advice, I often run into annoying problems that are often just fixed by being more organized. Besides, if his OP is a shitpost, my post is literally regurgitated shit.
On November 24 2015 23:31 Chef wrote:
Sure, it's not problem. I like to write methods I wish existed when thinking about the top level logic of my code, and then write the methods.
My bad about the scope, your methods are all in the global scope so they are accessible to one another.
ex
2.1.3 :001 > def bear; puts 'bear'; end
=> :bear
2.1.3 :002 > def kuma; puts bear; end
=> :kuma
2.1.3 :003 > kuma
bear
In larger applications, you have to throw things into classes and modules, so that you can avoid naming collisions by polluting the global scope (you can google javascript global scope for a typical explanation).
If for example you had defined method A within method B, you wouldn't be able to access method A outside method B. Similarly, if you define methods within a class, you can access them anywhere within the class, but outside the class you have to call Class.method (or if you have an instance of the class, instance.method).
I'm just saying your method chew does not describe accurately enough what it does, which is find food and digest it and vomit it out. So when someone calls chew they will get the unexpected result of vomit. Really your method would be accurately called find_food_eat_it_and_vomit_it_out which is a method that seems to have a lot of responsibilities. If I wrote such a method, it would have calls to three other methods, find_food eat_food (which has chew_food and swallow_food methods) vomit_food. This way the code is more reusable, the stack trace will be easier to read, and if you need to update one of them, all your methods that use them will be updates simultaneously, instead of you having to update the same code in multiple places.
Even if all you use code for is one off scripts for yourself, it might help you to build a library of methods you often need to use (which you could do a very simple require to have accessible in all your scripts, saving you some copy / pasting). Naming those methods logically will help you to remember without referencing them.
Sure, it's not problem. I like to write methods I wish existed when thinking about the top level logic of my code, and then write the methods.
My bad about the scope, your methods are all in the global scope so they are accessible to one another.
ex
2.1.3 :001 > def bear; puts 'bear'; end
=> :bear
2.1.3 :002 > def kuma; puts bear; end
=> :kuma
2.1.3 :003 > kuma
bear
In larger applications, you have to throw things into classes and modules, so that you can avoid naming collisions by polluting the global scope (you can google javascript global scope for a typical explanation).
If for example you had defined method A within method B, you wouldn't be able to access method A outside method B. Similarly, if you define methods within a class, you can access them anywhere within the class, but outside the class you have to call Class.method (or if you have an instance of the class, instance.method).
I'm just saying your method chew does not describe accurately enough what it does, which is find food and digest it and vomit it out. So when someone calls chew they will get the unexpected result of vomit. Really your method would be accurately called find_food_eat_it_and_vomit_it_out which is a method that seems to have a lot of responsibilities. If I wrote such a method, it would have calls to three other methods, find_food eat_food (which has chew_food and swallow_food methods) vomit_food. This way the code is more reusable, the stack trace will be easier to read, and if you need to update one of them, all your methods that use them will be updates simultaneously, instead of you having to update the same code in multiple places.
Even if all you use code for is one off scripts for yourself, it might help you to build a library of methods you often need to use (which you could do a very simple require to have accessible in all your scripts, saving you some copy / pasting). Naming those methods logically will help you to remember without referencing them.
So separating them into
def find_food()
stuff
end
def chew()
differentStuff
end
def swallow_digest()
otherStuff
end
def vomit()
endResult
end
def indigestion()
find_food()
while food
chew()
swallow_digest()
vomit()
puts "I'm hungry again"
end
indigestion()
would be better because it's easier to tell where something goes wrong when something goes wrong?
