# Reducing size of formulas / Cleaner Codes

Discussion and feedback on Construct 2

### » Tue Feb 07, 2012 12:19 pm

I have two important points for reducing formulas sizes.
In 90% of the time I find myself treating the X and the Y of objects in the same manner. In 90% of the time both parts of the formula (X and Y) get the same treatment.

When calculating the distance, for example, I get this:
Distance(ThisObject.X, ThisObeject.Y, ThatObject.X, ThatObject.Y)

I was wondering whether an introduction of a special word will help the code look more simple/clean/nice. The word can be one of these:
- Point
- Location
- Position

This will turn the previous line to something like this:
Distance(ThisObject.Point, ThatObject.Point)

In more complicated formulas this idea make them even cleaner.
This:

Will turn into this:

It looks more elegant.

This addition will also show the attribute "Point" in Object Expression. Instead of just X and Y, we'll have "Point". Wish to set position of one object to follow another? Simply set it to follow Object.Point or Object.Position

People who still need the inner X,Y separation can always use the regular X,Y reference as we do these days.

The second point I wish to bring up is - Function library. I was thinking it would be cool if people can share their functions with the community by saving/loading functions. This will help bring more power to current creations by using other's functions.
I already suggested this for objects so why not for functions.
Such Functions library will reduce formulas and turn the code into something fun.

The families (Great feature!) made the code cleaner. Hopefully these two points will contribute as well.HotGod2012-02-07 12:22:18
B
35
S
12
G
6
Posts: 111
Reputation: 7,087

### » Tue Feb 07, 2012 12:33 pm

Distance(ThisObject.X, ThisObeject.Y, ThatObject.X, ThatObject.Y)
Distance(ThisObject.Point, ThatObject.Point)
Distance(ThisObject, ThatObject)

Last one looks cleanter, IMHO.

If the expression can extract X and Y out of the object, it looks cleaner than the "point" alternative and avoids creating yet another construct.Fimbul2012-02-07 12:33:49
B
35
S
8
G
8
Posts: 532
Reputation: 6,868

### » Tue Feb 07, 2012 12:57 pm

Its more specific, and already implemented. :P
Ok yeah some arrays as variables would be nice, but that's probably way down on the list.
B
160
S
48
G
80
Posts: 7,245
Reputation: 61,518

### » Tue Feb 07, 2012 1:34 pm

@Fimbul: You're right of course. the Distance example you wrote about does look cleaner and it will be great to have such Function.

But I was talking about a less specific solution. When you wish to compare the locations of two objects you won't ask:
Does (ThisObject == ThatObject). such question doesn't make sense. What atribute of these Object you wish to compare?

Does (ThisObject.Location == ThatObject.Location)

The same goes with other C2 activities. Removing the .Point or .Location is cool but does present a too specific solution.
The solution I offered will simply add more flexibility and simplicity to most cases. Cases in which you wish to refer to the (x,y) as one unit.

@newt: This would be great. My point was to offer Self.Point or Self.Location as a more elegant way of referring to (x,y) as 1 entity (In addition to x and y as we have today)

Hope I made my Point clear... :)
B
35
S
12
G
6
Posts: 111
Reputation: 7,087

### » Tue Feb 07, 2012 3:55 pm

It's a good idea but very tricky to fit in to the expression parser and expression system, and the workarounds are perfectly reasonable and practical, so this is something it's more likely we'd push back to C3.
Scirra Founder
B
355
S
208
G
71
Posts: 22,839
Reputation: 176,804