@Tomot
You are over thinking this. ๐
You will need some spaces in any language's code, so that the 'parts' can be differentiated by the interpreter.
The only errant spaces you have flagged up so far are the ones I had previously warned against, and had been advised against in the earlier versions of Ruby too - because although they were 'tolerated' they could be deprecated and become unacceptable... and now they have been!
To reiterate...
A ' method' can sometimes take an argument or arguments [ .upto(666), .add_line(pt1, pt2), etc] - these arguments are always best passed inside parenthesizes ()... The opening ( should come immediately after the last character of the method, with no space between them.
So all you need to do is search for ' (' and then decide it you make it into a simple ' (' when it occurs immediately after a method.
Some spaces in code are 'optional' and using them simply helps 'readability' when editing - just like consistent indenting of code-blocks will - but again that was ever so:
e.g.
xx=12.3
v.
xx = 12.3
From what I've seen of your screen-grab images, you have sometimes included other () in parts of your code - sometimes they are not necessary at all.
if xxx && yyy
is fine.
if (xxx && yyy)
is too, but the () are NOT needed at all, unless you are nesting tests like this:
if xxx && (yyy || zzz)
when you need them...
All v2014 Ruby2.0 has done is to stop accepting some syntax that was already advised against in earlier versions too.
It has not 'moved the goalposts' - rather it has 'set them in firmer foundations'...
The advantages of v2.0 far outweigh the inconvenience of tidying up old poorly drafted code.
The few other minor changes in its methods, like 'array_to_string', actually bring it to be more aligned with other similar languages like Perl... These changes are unlikely to affect the vast majority of scripts anyway, and if they do they do then it is easily spotted and resolved anyway...
Be assured that if you scripts are updated and they work properly for you in v2014, then they should work for anyone else using the same version [and OS and Pro/Make***].
***If in the unlikely event that one of your scripts contain some OS specific or Pro [v.Make] methods/code then of course, without testing your script on the alternative OS/Pro compatibility cannot be ensured - but that was ever thus...
๐