Rights & Wrongs of Coding

[Andrew]

Xbytor posted regarding certain rights and wrongs of coding under the heading app.activeDocument on the Adobe forum. I thought it would be worth continuing some of that discussion here.

In the case in point, there is a PS js implementation bug which causes us to be unable to directly test for a condition as we would like. So we have various options how to get around the problem.

Xbytor in another thread writes

"You should not use a language's exception handling features for control flow.
You should only use try/catch blocks for _exceptional_ conditions/errors."

He also points out that where PSJS differs from standard JS syntax it would be good:

1. To have the difference documented (correctly).

2. To understand why it does so.

I don't think there would be much dispute above the latter two points, especially the first.

But to revert to the initial issue, here is my take on having to deal with getting round a scripting anomaly / gap.

1. The 'fix' should be effective for as much of the script writers target audience as possible (so if they are writing for Windows platforms, it should work on as many Windows versions as possible, and if it also works on Macs, all the better etc).

2. The fix should be as forwards and backwards compatible as possible with PSJS implementation.

Aiming for forwards compatibility involves second guessing Adobe - we won't always get it right but some approaches are more likely to succeed than others.

One aspect of this is that code which is based on PS behaving either incorrectly (a bug), or differently from the documentation, is more likely to cause future problems than code which is based on areas where the PSJS is working as expected.

To give an example, I pointed out on the Adobe forum some time ago that, in direct contradiction with the PSCS JS documentation, the rename function could be used to move files to different folders. While this is true, it does not make a good foundation for creating moveFile functions as there is a significant chance that Adobe will 'fix' the PSJS implementation to bring it in line with the documentation.

So despite being able to move files with rename it is probably better to do so by another method which is more future-proof.

3. The code should be as efficient as possible - both in terms of lines of script and, more importantly, in terms of CPU usage when the script is run.

4. The code should be as readable as possible while bearing in mind the code's efficiency.

5. The code should follow the underlying language structure and conventions as far as possible (to a degree this supports 4).

I'm sure there's lots more.

What interests me is that these various objectives do not always pull in the same direction nor is it clear (or stable) in which order these rules should be applied.

MickM's use of try / catch in testing for the presence of a certain layer-name is a case in point. I would say it scores well for 3 & 4, not bad for 1 & 2, poor for 5.

Personally I think it is a reasonable approach. Not the only solution but a good enough solution to merit sharing it with other coders. Similarly Xbytors suggested repackaging of a layer-test function is worth sharing.

I am an advocate of sharing a variety of solutions to coding problems. While I agree that often one way is better than another it is not always the case and in any case a lot can be learned from wrong ways too.

For my own coding I take a pragmatic approach. I do it as well as I can and I am always interested in learning to do things better but my focus is on getting the job done for my target purpose.

Andrew

[MickM]

Looks like that little snippet I posted on the Adobe forum has led to an interesting debate. In VB.NET there is no getbyname method so this is the only way to avoid a loop. In some cases there is no alternative at all - checking for a layer mask for example. I think the end justifies the means in these cases but I don't think it is good programming practice.

[xbytor]

Sometimes you gotta do what you gotta do. Adobe has definitions of containers (like Documents and Layers) and some attributes (like app.activeDocument) that are not in line with existing containers (Objects) or native JS properties.

So, there are times when a try/catch block is the most expedient solution. I was hoping that Tom from Adobe would jump into the discussion. Some of my comments were intended to draw him out .

That said, I am still thinking over what mechanism would be best to use to compensate for these non-obvious definitions.

The fact that I can override methods on a class in JS means that it may be possible to transparently replace the container methods while still providing access to the existing apis.

[Andrew]

I guess the point I was trying in my circular fashion to make was:

When we have a something called 'good practice' it is there for a reason, or more usually a collection of reasons (for example my simplified list of issues above).

Those reasons in turn are based on certain assumptions about the underlying conditions (for example the nature of the programming language).

If the conditions are close to optimal (a well designed language) and without bugs then generally the 'good practice' will stand. However when this is not the case the conclusion as to what is the best way to do things becomes less straightforward - and also more subject to the intention of the programmer and the specificity of the situation.

For example, if, using JS (to exclude the narrower VB situation) the try catch approach saves you looping through 100 layers then I do not think it is black and white as to which approach is the right one.

More practically for this forum, I would not like users to feel inhibited about posting non-standard solutions to scripting problems.

Discussing why one solution might be better than another is very worthwhile of course.

Andrew

[George E Smith]

The rights and wrongs of coding is like two car buffs arguing over which makes better cars Ford or Chevy.

The coding that works all the time and gets to market quickest is the best. Any thing else is un-important.