Let's share your beliefs in RMVXA scripting

[DoubleX]

Almost(if not just) all people have their own beliefs on our interested parts of the external world, so it's natural that we, as RMVXA scripters, have our own beliefs in RMVXA scripting too. Those beliefs will normally be reflected on our scripts.

Being aware of those of our beliefs can help us reflect upon them and hence possibly making our scripts more desirable to ourselves(present and/or future) and/or their targeting audiences/addressed situations.

This post aims to incite you to share at least some of your beliefs in RMVXA scripting and freely discuss what are shared here while still keeping an open mind.

While I want the discussions to remain explorative and open ended, it's also completely ok that they end up being countless and endless fierce heated debates, as long as they all remain civil and we're all still respecting each other.

I also want you to state how firm you hold the beliefs you shared here. Such degrees can be approximately classified into these 3 levels in my opinion:

Guidelines - You generally feel/think they're right in most cases but you still doubt there can be some unlikely exceptions, so you'll usually analyze whether they'll probably work on the specific cases before actually applying them.

Standards - You're so rigidly confident on them that you deeply trust that they're always universal truths unless they're solidly proven otherwise(in these cases you'll likely rethink on those beliefs instead).

Dogmas - You simply treat them as axioms so you'll instantly conclude that any contrary evidence must be itself problematic and can thus be safely discarded.

You don't have to conform to this categorization. It just serves as some examples to indicate how firm you hold your beliefs. For instance, you can say what you believe in are indeed undeniable facts.

I'll try my best to be as objective and rational as I can. I'll first try to thoroughly comprehend the beliefs shared here, then I might challenge them regardless of whether I agree with them or not.

With all these in mind, let's get started. I'll start by citing some of the examples I've gathered from the internet so far. Mentioning them here alone doesn't mean I agree nor disagree with any of them:

- Scripting is all about situation analysis and code quality balancing and prioritization. That's the only sliver bullet and golden rule in the scripting realm.

- Scripters should be user-oriented as they're to solve their users' demands. Write your scripts based on the requests instead of shoehorning the requests into your scripting ideals.

- Readability is relative to the readers and is hence subjective. The so called coding conventions won't work globally regardless of what their advocates claim.

- Save file failsafe should be a standard. There are in fact extremely rare edge cases but they can be handled entirely separately without compromising that standard a all.

- Using duct tape programming to fix bugs is like taking painkillers to cure fever. It'll never solve the root causes but only suppress their apparent symptoms so they should only be used in emergency.

- Time performance should always be highly prioritized. RMVXA demands extremely time performant codes to have satisfactory time performance in less powerful machines which should be taken into account.

- Rescuing an error implicitly rather than showing its log explicitly is just sweeping things under the carpet. It gives a false sense of correctness and robustness when the bugs are in fact never properly dealt with.

- Self-documenting codes instead of the so called necessary comments are what we really need. Comments are always mere useless liabilities as they never give any extra value while needing the scripters to maintain them.

- Verbose codes are inherently bad. Those needing codes to be verbose are simply not proficient enough with Ruby so it's just their own problems.

- Conform to the Model View Controller architecture implemented by the exposed parts of the default RMVXA codebase. The majority of the custom scripts adhere to the default and you'll face serious compatibility and readability issues if you don't follow.

- Premature abstraction is the root of all evil. Just remember that the codes need to be usable before they're reusable instead of making tons of 1-2 line methods just for the sake of the fake reusability.

- Personal preferences in scripting are excuses of blatant incompetence and inexperience. Ruby has its own well-established coding styles and best practices that are long tried and true by the whole Ruby community so just stick to them.

Although it's certainly healthy that we argue against beliefs that we disagree, I still want you to focus more on sharing your own. I think we can learn more from the others and perhaps ourselves as well this way.

P.S.: Instead of sharing mine now, I still want to continue to gather more such beliefs from the internet first lol

Edit: Gathered some more examples from the internet:

- Readability should take high precedence whenever possible. Properly use Ruby's expressiveness instead of abusing them to write the so called "compact" codes which serves no purpose other than code obfuscations which will always harm everyone.

- Script demos always end up doing more harm than good as too many users only abuse them to build their game based on those demos directly. Users needing demos to be able to use scripts should get better in RMVXA instead.

- We can sacrifice the original code compatibility when we've more important programming aspects to worry about and some of them conflict with compatibility. We can always write separate compatibility fixes to solve the issues when they come.

- Both global variables and eval are disastrous plagues and necessary evils at most. They're some of the best tools to kill a script and there are almost always better alternatives when you think you need them.

- Scripters should let others to edit their scripts and publish the edits as long as they're still conforming to the rest of the terms of use of those scripts. Otherwise those scripts will be effectively dead once those scripters are no longer active.

- Enterbrain should open source all the hidden RGSS3 classes like what they're going to do with RMMV. Doing so will do more good than harm to everyone including Enterbrain itself.

- Distributed version control's a must for any serious scripter working in any serious scripting team. Those thinking it'd be overkill would end up learning the truth the hard way.

- Writing commercial scripts that haven't reach the commercial qualities yet is ripping their users off. Those users will feel cheated when free scripts can already do what those commercial scripts do.

 

[Ramiro]

 

- Scripting is all about situation analysis, and code quality balancing and prioritization. That's the only sliver bullet and golden rule in the scripting realm.

 

There is no silver bullet in software development. Enough for this point.

 

- Readability is relative to the readers and is hence subjective. The so called coding style standard won't work globally regardless of what its advocates claim.

Nope, you should always remember yourself what you did in order to maintain it. Try to mantain a pile of spaghetti code first, then cry.

Formatting is important, and there is no subjetivity about that.

- Rescuing an error implicitly rather than showing its log explicitly is just sweeping things under the carpet. It gives a false sense of correctness and robustness when the bugs are in fact never properly dealt with.

No, rescuing an error is a way to handle it. 

Don't categorize a tool as bad if people give it bad usage

- Conform to the Model View Controller architecture implemented by the exposed parts of the default RMVXA codebase. The majority of the custom scripts adhere to the default and you'll face serious compatibility and readability issues if you don't follow this convention.

You should not do things like *cough* some scripters with V... *cough* and rewirte the classes to work different from the standard, still RM fails really bad to a MVC architecture in some areas, the use of managers for managers is a proof of it.

At least in RGSS3 this problem was almost completely solved, still there are traces of mixed view-controller.

Why obj.string? while you can do obj.is_a?(String) one will never guess... *grrrr*

- Premature abstraction is the root of all evil. Just remember that the codes need to be usable before they're reusable instead of making tons of 1-2 line methods for the sake of the fake reusability.

Method size for object purist is 5 (+/-) 2 in other words, betwen 3 and 7, 1 line methods are usually not recommended, unless that line transfers a lot of meaning, wich usually happens in ruby, also consider this for accessors.

- Self-documenting codes instead of the so called necessary comments are what we really need. Comments are always mere useless liabilities as they never give any extra value while needing the scripters to maintain them.

It might not add any value, but comments gives you a general description of a method.

Hey, while you know, while

#=====================================================# Informs the boss#=====================================================def inform_to_bossendIs silly, your way of comments, not comments itself

Your comments should be:

#=====================================================# Generates a report about the latest changes on the project, then sends the report to the boss#=====================================================def inform_to_bossendThis will be better from any point of view.

o the other points more or less I agree, there are its problably this can't be done in X situation, but that is because There is no Silver Bullet...

 

[DoubleX]

Re #2:

Good to see how you argued(agree or disagree) with those examples I gathered from the internet so far(although I remain neutral on all of them as I'm quite a skeptical person on both the external arguments and my internal thoughts).

Now I try to gather your beliefs shared here that's different from those examples(again they're just examples):

- The only so-called "sliver bullet" in RMVXA scripting(actually software development in general according to what you've said) is "there's no sliver bullet".

- Proper code formatting is 1 example of objective readability, like spaghetti codes being 1 objective counterexample(I assume you think that there exists objectively better formatting and objective ways to judge spaghetti codes).

- There are truly legitimate uses of rescue. Just because a tool's misused and/or abused doesn't mean it's itself bad.

- Comments can have its own values. An example is to clearly show the intent of the methods when the method names themselves wouldn't be suffice.

About the MVC thing, I don't think right now I've enough knowledge to really grasp your points

I'd be glad if you share more of your beliefs in RMVXA scripting here

P.S.: Gathered some even more beliefs from the internet:

- Readability should take high precedence whenever possible. Properly use Ruby's expressiveness instead of abusing them to write the so called "compact" codes which serves no purpose other than code obfuscations which will always harm everyone.

- Script demos always end up doing more harm than good as too many users only abuse them to build their game based on those demos directly. Users needing demos to be able to use scripts should get better in RMVXA instead.

- We can sacrifice the original code compatibility when we've more important programming aspects to worry about and some of them conflict with compatibility. We can always write separate compatibility fixes to solve the issues when they come.

- Both global variables and eval are disastrous plagues and necessary evils at most. They're some of the best tools to kill a script and there are almost always better alternatives when you think you need them.

Feel free to share your thoughts on these examples as well as sharing yours

 

[Ramiro]

Mixed Model-Controllers are most of the 'Game_' classes.

RPG::Actor is purely a model, only stores data

Game_Actor is a model because:

•  Stores your save data of the current actor.
•  Validates the data you change of it.

But is also a model because:

•   It comunicates directly into the views.
•   There is no controller managing your actor but itself.

If you prfer to make it a "pure mvc" you should have a Data_Actor wich only evaluates data and an Game_Actor wich orders how to control the actor.

So the method learn_skill(id) should be part of Game_Actor, but the skills should be saved on Data_Actor...

Granted for RM games is too much classes, but this has the "advantage" than you can replace Data_Actor without altering the information or vice-versa.

This is more notable when you are making things on static languages, like C# you can change just the "Model dll".

Ruby with open classes actually defeats almost all of the advantages of using MVC, you can just change what you need.

Yes, there are ways to justify bad code:

x  = ((x ? ([2, 3]) : (x.is_something? : [] : Array.new(52)).collect{ |v| v.to_s }).select { |x| x == 'a'  }Overusing, mixing styles, avoid meaning in your variables, not documenting are all ways to produce bad code, specially when you are method chaning for the sake of method chaining.

But of course, that is all coming from a 'oo purist' wich may lead to some bad implications in many ways.

Having good code, easy to read, easy to mantain and formatting it well will help you, not the user, so while not important for the user, it is important.

 

[_Shadow_]

I am not fluent in Ruby, and will not probably be, since the new maker will be based on JS.

I am fluent on other languages though. So Ruby is a scripting languages and the statements above apply to any scripting language.

To be fair, I will focus on the RPG Make VX Ace scripting only and try to reply to every statement expressing my opinion.

 

 


- Scripting is all about situation analysis, and code quality balancing and prioritization. That's the only sliver bullet and golden rule in the scripting realm.

 

The situation must be observed by the right perspective and the right angle. Because people usually have one of each, they rarely make correct decisions alone. That is why programmer group meetings exist. And that is why forums like this exist too.

I can't say that this statement is wrong. You just have to understand what "situation analysis" means.   

 

 

- Scripters should be user-oriented as they exists to solve their users' demands. Write your scripts based on the requests instead of shoehorning the requests into your scripting ideals.

 

Well this is correct, because user's demands is a blurry thing. Here comes the problem though. Users don't know their needs from scratch. That's why analysts exist. It's their job to discover them. But as I read this line, it seems fine to me. I mean, a need might be "full compatibility with ALL other scripts out there". Good luck with that!

 

 

- Readability is relative to the readers and is hence subjective. The so called coding style standard won't work globally regardless of what its advocates claim.

 

There are global guidelines for readable code. Imagine you write code, that is meant to be read by a child that just learned how to read.

You can explain everything. Someone who hates SUCH much explaination can erase the comments to read things easier.

Someone who needs instructions though, can't write them himself/herself or he/she could write the code too.

It depends. Especially when it comes on scripts you sell to the public, you must have documentation inside your code.

 

- Save file failsafe should be a standard. There are in fact extremely rare edge cases but they can be handled entirely separating without compromising the standard a all.

 

This is not right. Actually making a rogue like lite rpg game, you have to break this standard.

But as long as it isn't on game rules, you should protect the gamer's saves. It's their time spent there. It is really irritating losing that. 

 

 

- Using duct tape programming to fix bugs is like taking painkillers to cure fever. It'll never solve the root causes but only suppress their apparent symptoms so they should only be used in emergency.

 

I STRONGLY believe that. Using duct tape programming to do ANYTHING, is bad practice. Same story on Javascript and many more scripting languages. Spaghetti code is the worst thing to do. You must know how to use all the tools available to do a well structured sequence inside methods and of course, know how to code using object oriented benefits. It isn't easy. Trust me.

 

 

- Time performance should always be highly prioritized. RMVXA demands extremely time performant codes to have satisfactory time performance in less powerful machines which should be taken into account.

 

Actually RPG Maker being slow, is not a status quo that should be taken for granted on scripting. First off it does not use GPU but only CPU to start with. That alone is bad. Is it 32 or 64 bit? So there are issues beyond Ruby scripting. 

But hey, look! There ARE some issues on Ruby scripting too. @SOURCE made Effectus script. It was a brilliant reengineering of the whole RGSS3 core, that increased performance dramatically. So that argument applies on RGSS3 core too, and yes it is right. And you should take into account old hardware for sure. The problem is that some methods, need CPU and time to work well by default. Of course we can all see how Khas made his own dlls to use with Khas Ultimate Light scripts. And he nailed it. Super performance.

 

 

- Rescuing an error implicitly rather than showing its log explicitly is just sweeping things under the carpet. It gives a false sense of correctness and robustness when the bugs are in fact never properly dealt with.

 

If the error does not affect performance and if you are 100% sure that this error will not cause any problems on a future upgrade of the script then go on and hide it under the carpet.

The problem is, you are NEVER 100% sure about ANYTHING.  So I believe this is correct. On the other hand, this might be a correct way to handle an exception (I assume bug = exception for that person)

 

 

- Self-documenting codes instead of the so called necessary comments are what we really need. Comments are always mere useless liabilities as they never give any extra value while needing the scripters to maintain them.

 

In my personal opinion this is 100% wrong. But I can understand what this person tries to say. The fact is that it really needs work to make right documentation.

 

A] Make a documentation on the build for you and any other coder that might maintain it. This is technical documentation.

B] Make the user documentation script. This will help people understand it, tweak it and use it easier. 

 

 

 

- Verbose codes are inherently bad. Those needing codes to be verbose are simply not proficient enough with Ruby so it's just their own problems.

 

Wait. This is the guy's problem really. I don't know if he/she was lazy or had an inability to describe how things work on the code he/she was writing.

Code CAN ALWAYS BE VERBOSE if you use comments to document it correct.If you are paid for a script this is expected and it is YOUR problem as a coder.

If the guy was talking about a free script, well I don't blame him/her. Not everyone can spend a lot of time documenting this **** right?

 

 

- Conform to the Model View Controller architecture implemented by the exposed parts of the default RMVXA codebase. The majority of the custom scripts adhere to the default and you'll face serious compatibility and readability issues if you don't follow this convention.

 

It depends on the script purpose. Imagine telling that to a delvoper of an anti-lag script. The problem with EACH individual script is that there are contadicting goals.

I will try to use a simple example to show such a contradiction. You must think if it would be a good idea to break this rule and just make a bunch of small patches.

It wouldn't be an issue if EVERYONE would code with compatibility in mind, but hey, life is unfair, let's get used to it.

I want fancy graphics for the Operating System I develop. But I want my OS to be old hardware friendly and also not consume too much CPU power and RAM.

Fancy interface and resources economy are two contradicting goals here.

That's why Operating Systems.use setting so you can adjust them to your own resources and needs actually.

Same happens everywhere if you think of it. I wanna go to the cinema to feel great, but my girlfriend wants to go to the opera. What shall I do?

So it depends. I stay neutral to this.

 

 

- Premature abstraction is the root of all evil. Just remember that the codes need to be usable before they're reusable instead of making tons of 1-2 line methods for the sake of the fake reusability.

 

That depends. But this is a good point. Breaking the code to a molecular level, without getting something in compensation, is just not so smart.

You should break (abstract) the classes in a way it will be efficient and there won't be any upgrade or extention problem in the future. 

Breaking everything into a "molecular level" makes sure you have a lot of flexibility. The question is, is that flexibility needed?

An analyst should know. Someone who follows the principles blindly, would do that in a place not needed, making it more complex to use.

 

 

- Personal preferences in scripting are excuses of blatant incompetence and inexperience. Ruby has its own well-established coding styles and best practices that are long tried and true by the whole Ruby community.

 

Is he/she talking about VX Ace here or Ruby in general? According to where that was taken from, I would react differently. Thus I express no opinion on this yet.

 

[DoubleX]

So far you guys focused on the examples I've brought here

Re #5:

Good to see how you argued(agree or disagree) with those examples I gathered from the internet so far

Now I try to gather your beliefs shared here that's different from those examples:

- Teams generally perform better than individuals when it comes to situation analysis, as multiple people can bring multiple angles of views and different perspectives. It's extremely hard for 1 single person to do that.

- To be even more user-oriented, scripters should try to analyze the users' demands instead of taking them literally.

- It's better to tune the codes, comments and documentations for the less able readers when it comes to readability. Less able ones generally need them while more able ones can simply ignore and/or discard them.

- While it's true that the default RMVXA demands extremely time performant codes, we should try our best to improve the defaults to make itself more time performant before giving up and sticking to the so called "status quo" instead.

- Properly written documentations are called for at least sometimes, as you'll have to think about your fellow scripters and your future selves.

About the save file failsafe thing, that example actually talks about unintentionally breaking old save file due to coding mistakes(although there could be cases where specific patches for specific projects would be needed). What you're talking about is game design and I thought the difference was clear enough. That's 100% my fault though

About the self documentation vs comment thing, that example actually solely talks about the script implementation parts(it's not gathered from the RM community at all). Most users won't read the code implementations(they also don't need to and some of them aren't able to yet) so I thought user configuration documentations are given. Not making it clear enough is again 100% my fault though

About the verbose thing, maybe I don't know what verbose codes really mean, but it seems to me they generally refer to something like this(modified from DoubleX RMVXA Object Trace):

Spoiler

#----------------------------------------------------------------------------| # Combines all the subtrees to form the whole original object trace tree | #----------------------------------------------------------------------------| # klass: The class of all objects to be traced # index_klass_symbol: The index/key/symbol of the object trace # object: The object to be traced def recursive_object_trace_tree_traversal(klass, index_klass_symbol, object) if object.is_a?(klass) == true # Checks if the object belongs to klass # Uses a klass name symbol to mark that this object belongs to klass symbol = "#{klass}".to_sym @object_trace[klass][index_klass_symbol] = [symbol] # end object.trace_object(klass) # Forms the object's object trace tree trace = object.object_trace[klass] # Store's the object's object trace tree unless trace.empty? == true # Checks if the stored object trace tree's empty # Stores an empty array if the original object trace tree's nil if @object_trace[klass][index_klass_symbol].nil? == true @object_trace[klass][index_klass_symbol] = [] end # # Links the object's object trace tree with the original object trace tree @object_trace[klass][index_klass_symbol].push(trace) # return end return end # recursive_object_trace_tree_traversal

I remain neutral on verbose codes, but I just want to make sure I accurately grasp what they mean

About the personal preferences thing, you can think that that example's meant to apply in both cases, as I recall sawing this belief both inside and outside the RMVXA community.

I'd be glad if you share more of your beliefs in RMVXA scripting here too

 

[Ramiro]

Let me take piece by piece your code:

#----------------------------------------------------------------------------|# Combines all the subtrees to form the whole original object trace tree |#----------------------------------------------------------------------------|# klass: The class of all objects to be traced# index_klass_symbol: The index/key/symbol of the object trace# object: The object to be tracedThis is good, you are explaning what this does, and what the arguments should be.

def recursive_object_trace_tree_traversal(klass, index_klass_symbol, object)This is probably too long as a name. probable 'trace_traversal_tree' should be better, as a norm, you should always start methods with a verb 'do_this', 'take_that', 'summon_dog', etc because you know, they imply 'actions' and in our language 'action' is more or less a 'verb'

Accessors are except from this last part in ruby, of course, but they are 'not methods' on the strict sense (and the 'real' way is set_name... with 'set' as a verb, see?)

if object.is_a?(klass) == true # Checks if the object belongs to klassThis is completely unnesesary, you know how  you should reduce your code to a more documented version of:

if object.is_a?(klass)"just reading it" transfers the meaning.

This obviously transferts to all your comments on line by line.

You shouldn't comment things like:

data = [1, 2, 3]        # stores the datasum = data.sum_all      # adds all the data togetheravg  = sum / data.size  # divides the total by the size of the datato the real way to use comments should be something like this:

#calculates the average number inside data and stores it on avg  data = [1, 2, 3]              sum = data.sum_all      avg  = sum / data.size  

 

[_Shadow_]

"- It's better to tune the codes, comments and documentations for the less able readers when it comes to readability. Less able ones generally need them while more able ones can simply ignore and/or discard them."

I prefer making differen versions of my code.

1] Plain compacted code

2] Same as 1 but with spaces and well indented.

3] Commented for developers

4] Commented for end user if available.

That way there will be only the needed comments for each "audience".

I also curse myself sometimes for the clusterf@#$k I made adn write a reminder to re-engineer the whole thing.

- While it's true that the default RMVXA demands extremely time performant codes, we should try our best to improve the defaults to make itself more time performant before giving up and sticking to the so called "status quo" instead.

We agree here! I wish I could help but I won't master Ruby at least at the present and near future.  

About the save file failsafe thing, that example actually talks about unintentionally breaking old save file due to coding mistakes(although there could be cases where specific patches for specific projects would be needed). 

Oh, of course, someone MUST protect a savegame. I think the problem is the absence of initial values on new variables that MUST contain something. I mean, Ruby is not like JS. You HAVE to fix suxh issues and that's a good thing in my opinion. JS can turn into hell.  

Script implementation should be contained no matter what. And it should be easy to read and tweak. A fantastic example of such a script is Luna Engine of course.

Incredible script collection.

Well verbose code is a well documented one. You should describe using certain standards a class for example, its methods and utility and its mission and of course how it can be used. An example is always welcome. Verbose code means I read it and understand it INSTANTLY. Even great coders that code in their sleep and debug somethnig just for warming up, should see a certain way of coding. I never saw a developer complaining about that, while I saw many ranting about their co-developer's laziness. 

You see a part of a code, you read English and understand what it is supposed to do and how to use it instantly. You might don't give a damn about how it does that at the moment. You might actually wanna use it. If it comes to fixing - debugging - extending- enhancing, then you read deeper and there should be some comments to also guide you through something that might be a little complex to understand instantly.

def recursive_object_trace_tree_traversal(klass, index_klass_symbol, object)This is probably too long as a name. probable 'trace_traversal_tree' should be better, as a norm, you should always start methods with a verb 'do_this', 'take_that', 'summon_dog', etc because you know, they imply 'actions' and in our language 'action' is more or less a 'verb'

It depends on the size of the project. It is good to keep names small for many reasons, as long as you can understand easily what is what.

. 

#calculates the average number inside data and stores it on avg
#start                                      < Sometimes people need these to get it

  data = [1, 2, 3]            
  sum = data.sum_all    
  avg  = sum / data.size  

#end                                       < I am dead serious

to make sure the user understands the block of commands you refer to, or use a STANDARD form of spaces that is followed everywhere.

Well I believe that you can have your style as long as you make your code beloved by your coworkers.

 

[Ramiro]

#calculates the average number inside data and stores it on avg#start                                      < Sometimes people need these to get it  data = [1, 2, 3]              sum = data.sum_all      avg  = sum / data.size  #end                                       < I am dead serious

This is true, you may need to put #begin and #end, but if that is the case, you still may need to do this then:

def calculate_average(data)  sum = data.sum_all      return sum / data.size  # <- explicit return is better to read, slower on code, one lines may ignore the return, but multilines notendif a piece of code is enough to be put inside a #begin and #end it may be better as a method (private when you can)

of course you can still reduce this as:

def calculate_average(data)  return data.sum_all   / data.size endOr finally as:

data.averageBut people usualy hate 'monkey patching' so for purist, not even 'sum_all' is acceptable. 

It depends on the size of the project. It is good to keep names small for many reasons, as long as you can understand easily what is what.

While sometimes you can't avoid it, like in alias if you try to avoid any chance of name collision:

alias myself_script_name_method_name method_namelike:

alias ramiro_m3battle_update_basic update_basicI suggest to avoid long names, but still you need to start them with a verb.

recursive_object_trace_tree_traversal should be as a 'long' alternative 'trace_object_in_traversal_tree_recursively', while 'not good' it starts with a verb wich is the important part.

 

[DoubleX]

Before challenging yours, I'd like to show my approach on challenging such beliefs using those examples I gathered from the internet:

Belief - Scripting is all about situation analysis and code quality balancing and prioritization. That's the only sliver bullet and golden rule in the scripting realm.

Challenge - It seems to me that sometimes it's both possible and allowed to change the situations to be more desirable for both the scripters and the users. When that's the case, I guess it'd be better to do so instead of forcing ourselves to deal with the less desirable situations. In short, I think changing the situations when they're allowed and called for is also a part of scripting, so I don't think this belief's a sliver bullet nor golden rule.

Belief - Readability is relative to the readers and is hence subjective. The so called coding conventions won't work globally regardless of what their advocates claim.

Challenge - "The so called coding conventions won't work globally" implies "subjective" here means nearly 100% subjective, meaning readability elements that apply to almost all people are nearly nonexistent. That's an assumption made by this belief, which will be at least partially flawed if this assumption's broken. In fact, it's broken as both science and the mankind experiences have long proved that some general readability elements apply to almost all people. As reading codes are just specific types of reading, those objective readability elements should apply there too.

Belief - Verbose codes are inherently bad. Those needing codes to be verbose are simply not proficient enough with Ruby so it's just their own problems.

Challenge - There are some scripts which are mainly written as learning tools for beginning Ruby coders. Most of them probably needs extraordinarily verbose codes in order to learn from those scripts effectively and efficiently. Therefore I think that in some rare special cases like this, verbose codes can at least do more good than harm.

Again, feel free to share more of your beliefs in RMVXA scripting

 

[Sarlecc]

I'm going to have to come back to this thread so I can finish reading all these points, seeing as I am always trying to improve my own coding practices.

- Personal preferences in scripting are excuses of blatant incompetence and inexperience. Ruby has its own well-established coding styles and best practices that are long tried and true by the whole Ruby community so just stick to them.

I am wondering on this one...

Lets say I have an Array and I want to push something to the end of said Array well I have two methods I can use:

array = []array.push(1)array << 2Now I have had no formal schooling on Ruby but my "personal preference" is to use <<. (As it is shorter, however it does remove some readability). If given two methods to do the same thing then won't some people naturally develop a preference on which one they like using?

 

[DoubleX]

Re #11:

It seems to me that "personal preferences" vs "well-established coding styles and best practices that are long tried and true by the whole community" is an fierce heated ongoing debate, which actually happens to the general programming realm as well.

I've read countless flame wars on the internet about stuffs like "always use space indentation vs always use tab indentations vs they're just personal preferences", "always return explicitly vs always return implicitly whenever possible vs they're just personal preferences", and many other similarly bloody fights.

There are different advocates standing for different coding styles and practices that they are so deeply root on them that they claim that they're the coding standards, so they end up arguing against the others intensively.

There are also some confidently trusting that they're just personal preferences so they state that these discussions are merely meaningless, pointless and useless rants.

I'm not saying they'll inherently lead to irrational personal insults though, but from what I've read and searched from the internet, most of them just ended up that way.

Nevertheless, I still found them interesting though

I'd glad to see you shared your beliefs here. Wish you'll share more

 

[Engr. Adiktuzmiko]

- Using rescue just so the code will proceed is not a good idea. Use it to handle the error, not to skip it. Error handling was there for a reason.

Scripters should be user-oriented as they're to solve their users' demands. Write your scripts based on the requests instead of shoehorning the requests into your scripting ideals.

- If ur taking a request, then yes.


- Allow easy configurations of the basic parts of your script, don't make the users touch the "core" and change things directly.


- If it's a publicly released script, make sure you write in a good documentation of how to implement your script.


- I go for readability in RGSSx for public scripts at least. IDK how it handles things, like if it's the same with the JASS of warcraft 3 where longer names take longer time to process or if the differences are noticeable enough or something. Back then on wc3, we scripters always go for which algorithm will run the fastest.

 

[DoubleX]

Well verbose code is a well documented one. You should describe using certain standards a class for example, its methods and utility and its mission and of course how it can be used. An example is always welcome. Verbose code means I read it and understand it INSTANTLY. Even great coders that code in their sleep and debug somethnig just for warming up, should see a certain way of coding. I never saw a developer complaining about that, while I saw many ranting about their co-developer's laziness. 

You see a part of a code, you read English and understand what it is supposed to do and how to use it instantly. You might don't give a damn about how it does that at the moment. You might actually wanna use it. If it comes to fixing - debugging - extending- enhancing, then you read deeper and there should be some comments to also guide you through something that might be a little complex to understand instantly.

Let's see if I can really get your definition on verbose codes(modified from DoubleX RMVXA Object Trace):

Spoiler

#----------------------------------------------------------------------------| # Combines all the subtrees to form the whole original object trace tree | #----------------------------------------------------------------------------| # klass: The class of all objects to be traced # index_klass_symbol: The index/key/symbol of the object trace # object: The object to be traced def traverse_tree_recursively(klass, index_klass_symbol, object) # v1.01a+ if object.is_a?(klass) # Uses the klass name symbol to mark that this object belongs to klass @object_trace[klass][index_klass_symbol] = ["#{klass}".to_sym] # end object.trace_object(klass) # Forms the object's object trace tree trace = object.object_trace[klass] # Stores the object's object trace tree return if trace.empty? # Appends the object's object trace tree to the original object trace tree (@object_trace[klass][index_klass_symbol] ||= []) << trace # end # traverse_tree_recursively

If your definition's correct, then most of the results I found when searching for verbose code on the internet are actually talking about overly verbose codes

P.S.: About this line of code:

(@object_trace[klass][index_klass_symbol] ||= []) << traceIt's extremely similar to this:

($imported ||= {})[:script_name]Which is so popular among RGSS3 scripts that it almost becomes an idiom in the RMVXA scripting community

Again, right now I just want to make sure I didn't misunderstand anything

 

[Zeriab]

Interesting topic DoubleX

From a commenting perspective I prefer writing comments about we do now rather than what it does.

Take the average example. Commenting and naming-wise I would prefer something like this:

  # Calculate average  data = [1, 2, 3]              sum = data.sum_all      average  = sum / data.size
Considering more kinds refactoring I would follow Ramiro's post.

As another example taking your code from the previous post:

Spoiler

  #----------------------------------------------------------------------------|  #  Combines all the subtrees to form the whole original object trace tree    |  #----------------------------------------------------------------------------|  # klass: The class of all objects to be traced  # index_klass_symbol: The index/key/symbol of the object trace  # object: The object to be traced  def traverse_tree_recursively(klass, index_klass_symbol, object) # v1.01a+    if object.is_a?(klass)      # Uses the klass name symbol to mark that this object belongs to klass      @object_trace[klass][index_klass_symbol] = ["#{klass}".to_sym]      #    end    object.trace_object(klass) # Forms the object's object trace tree    trace = object.object_trace[klass] # Stores the object's object trace tree    return if trace.empty?    # Appends the object's object trace tree to the original object trace tree    (@object_trace[klass][index_klass_symbol] ||= []) << trace    #  end # traverse_tree_recursively

A first revision of the comments only I would be more explicit with fewer words:

Spoiler

  #----------------------------------------------------------------------------|  #  Combines all the subtrees to form the whole original object trace tree    |  #----------------------------------------------------------------------------|  # klass: The class of all objects to be traced  # index_klass_symbol: The index/key/symbol of the object trace  # object: The object to be traced  # version: v1.01a+  def traverse_tree_recursively(klass, index_klass_symbol, object)    if object.is_a?(klass)      # Mark that this object belongs to klass      @object_trace[klass][index_klass_symbol] = ["#{klass}".to_sym]    end    # Perform trace    object.trace_object(klass)    trace = object.object_trace[klass]    return if trace.empty?    # Append trace to the original object trace tree    (@object_trace[klass][index_klass_symbol] ||= []) << trace  end

Also, I have a sentence of my own: Consistency in style is more important, even if it's only a good style, than switching between styles in your same code base.

I may come back later, if I don't forget it

*hugs*

 - Zeriab

 

[DoubleX]

Gathered some more beliefs from the internet:

- Scripters should let others to edit their scripts and publish the edits as long as they're still conforming to the rest of the terms of use of those scripts. Otherwise those scripts will be effectively dead once those scripters are no longer active.

- Enterbrain should open source all the hidden RGSS3 classes like what they're going to do with RMMV. Doing so will do more good than harm to everyone including Enterbrain itself.

- Distributed version control's a must for any serious scripter working in any serious scripting team. Those thinking it'd be overkill would end up learning the truth the hard way.

- Writing commercial scripts that haven't reach the commercial qualities yet is ripping their users off. Those users will feel cheated when free scripts can already do what those commercial scripts do.

I hope I can incite more of you to share more of your beliefs by continuing to gather more beliefs from the internet