I dont want to call out any scripts or projects for being poorly coded. As you said:
In our forum many script / project authors publish their "babies".
But it really helps if you enumerate a 'bad' scripts list here (Even if it contains some I wrote )
But I will say that Vista & Win7 (Including my own ShadowPE) are the projects with the most poorly written scripts.
I would say this is mainly to do with that Win7PE started out as a hacked together version of VistaPE with changes simply made to get the script working.
Which is fine:
Sure, they may produce some spaghetti code at first attempts, and maybe also at second and third attempt, but it will be WORKING spaghetti code , and little by little the code will be every time a little less "spaghetti like" and a lot more "proper code like", and this wil possibly better the name of Winbuilder, which may attract more members and from them a small percentage will learn to write a .script, and then a better written .script .....
Once that was complete changes and upgrades could be made and the project has come along way and everyone can be proud of what the developers here have accomplished.
My main point is that PE's like vista and win7 based ones are starting to get to the point where there are so many scripts that at one point worked and then stopped working for whatever reason but were patched are becoming almost impossible to manage as the changes are so rapid.
(I mean no offence to any of the developers/maintainers of these scripts/projects as they are fantastic! I am simply making an example.)
Once a project gets to this point the only logical step would be to either do modifications that would break many scripts (which could lead to the same problem) or to do a complete rewrite of the project and set standards that would break every script but once they are rewritten to follow the new standard would be easier to maintain.
I think the second option makes more sense because many scripts can easily be converted. Others would need to be rewritten from the ground up.
I'm really not trying to step on anyones toes here. Project Standards would help new users make scripts because many people would be able to guide them to following the standards set by the project to maintain compatibility.
It may also help to keep a manual for each stable version of WinBuilder this way developers could see the changes between syntax and either not support a version of WinBuilder or upgrade their script.
Wonko is yet again correct that scripts stop working for a reason and not everyone has time to maintain them. It is also up to the developer to decide how much documentation will be available to the end-user.
Willing developers do need to be helped, if we dont that would be the end of WinBuilder.
I guess my biggest point is that project developers need to set standards that will allow us to solve our MAIN issues:
- "poor" coding
- "poor" GUI design
- "poor" integration/assembly of single .script in projects
- "poor" mantaining of the .script or project
- Can be caused by lack of understand as to why things were done a specific way (Documentation)
- Lack of structured UI design
- This can be caused by lack of project documentation or simply lack of WinBuilder knowledge (When learned the scripts can be improved)
- If standards are set anyone can make sure a script stays updated
A script to a Project is like a Project to WinBuilder, if the parent has major changes the child can either flourish or suffer.