How do compilers read your code

[fs_tigre]

Hi,
I should probably know this by now and think I read this somewhere but I want to hear it from the experts in a clear way.
I believe compliers read (flash on my case) Actionscript 3.0 code from top to bottom right?
Does that mean that the placement of your code makes a difference in the action it may take?
Sorry if this is so obvious!

Thanks a lot

[komapeb]

Yes. You're right. From top all the way to the bottom. And it makes difference. :)
Here's one case:


play();
stop();

Here the movie stops playing after the last line.

Another one:


stop();
play();

Here the movie stops playing after stop() but you can't actually see it because right after the 1st line there's a play() which causes the movie to continue playing.

[fs_tigre]

Thanks a lot for the clarification.

[komapeb]

You're welcome :)

[fs_tigre]

First of all thanks a lot!

So, Is the placement of code something the developer should to be considering while coding?

Is this part of the coding process?

I know most of the time it make sense where to put your code but how about for more complex situations.
I’m just trying to understand how the pros think when coding, and of course start thinking more as a developer.

Thanks

[Shaedo]

"So, Is the placement of code something the developer should to be considering while coding? "

There are a few schools of thought on this, and certainly people will have strong opinions. One is the code as you go approach. Recently espoused by some of the top AS3 coders at an AS3 coding conference it basically goes along the line of jump right in and start coding, work things out as you go along. IMHO this is ok for 'soloists' but is untenable as an approach for larger projects involving multiple devs

The opposite to this is the draw a good diagram of what and how your classes will interact, what data will go to and from each object. Then create your classes and write in your functions (but leave them blank) then only when you have all your frame work ready will you fill in the actual code for the functions. IMHO this is good for large projects and ensures the code written by one person will sync/be compatible with others.

More specifically you should place you code in such a way that it is readable. This means firstly that someone can look at the code and work out how to interact with it - this is why typically you will see the public functions put above the private ones.

Secondly make it logical. So as the order of functions generally does not matter lump more related ones together.

In more complex situations Good OOP practice will help you to work out if you code should be say across two classes or in just one. Your considerations are generally things like:
how scaleable is your code? - can I add more functions?
how readable is my code? - can I make sense out of it in 6 months? can someone else make sense out of it?
how functional is my code? - do I do a lot of unnecessary work ? how important is my functionality compared to adhering to OOP practices (or good procedural practices if you are coding proceduraly) or readability or the coding SOPs for my client or organisation ?

You should be aware the even though the compiler may read your code from top to bottom, it does not necessarily run it in that order for example the declaring of a var is done before other code but the assigning of a value is done in the order typed:

var b:String;
TS(a);//string is null // recognises that there is a var 'a' but has no value assigned
TS(b);//string is null // recognises that there is a var 'b' but has no value assigned even though it is declared later in the code
//TS(c);//1120: Access of undefined property c. // as there is no var c declared it would give an error
function TS(s:String):void
{
trace('string is ' +s);
}
var a:String = '1234'
b = 'abcde';
TS(a);//string is 1234
TS(b);//string is abcde

[fs_tigre]

Very nice! Thanks a lot for the good explanation.

[BoppreH]

var b:String;
TS(a);//string is null // recognises that there is a var 'a' but has no value assigned
TS(b);//string is null // recognises that there is a var 'b' but has no value assigned even though it is declared later in the code
//TS(c);//1120: Access of undefined property c. // as there is no var c declared it would give an error
function TS(s:String):void
{
trace('string is ' +s);
}
var a:String = '1234'
b = 'abcde';
TS(a);//string is 1234
TS(b);//string is abcde
Just adding that function declarations also follow this rule. In this case, TS could be placed at the end of the code and still works.

But as a rule of thumb, group similar things together and as near to use as possible.