Question Making a code smaller

B

BobyIsProgress

Member
Hi,

Is there a way to reduce the number of line of this code:
Code: 
IF cError <> "":U THEN DO:
    MESSAGE cErrorr SKIP(1)
            "Impossible to update"
        VIEW-AS ALERT-BOX ERROR BUTTONS OK.
RETURN .
END.

Best Regards,

- Vivien -
 
Do you mean something like this?
Code: 
if cerror > "" then do: message cerror skip(1) "Impossible to update":u view-as alert-box error. return. end.
:p
 
On a more serious note - depending on the rest of your infrastructure:
Code: 
&scoped-define error-impossible-to-update 44006 /* this belongs in an error number include */
if cerror > "" then 
   undo, throw new Progress.Lang.AppError( cerror, {&error-impossible-to-update} ).
 
Stefan said:
On a more serious note - depending on the rest of your infrastructure:
Code: 
&scoped-define error-impossible-to-update 44006 /* this belongs in an error number include */
if cerror > "" then
   undo, throw new Progress.Lang.AppError( cerror, {&error-impossible-to-update} ).
Click to expand...
Yes it should be the right way to do it with a better error management.
 
TomBascom said:
Every program can be at least one instruction shorter and still contains at least one bug.

Therefore... every program can be reduced to one instruction which is wrong.
Click to expand...
yes I understand your point of view @TomBascom . My issue here is that the "procedure" I wrote is longer than the editor can accepts. So if I want to update it, I have to open my .w file in a procedure editor. (BTW OE10.2B)
 
BobyIsProgress said:
My issue here is that the "procedure" I wrote is longer than the editor can accepts. So if I want to update it, I have to open my .w file in a procedure editor. (BTW OE10.2B)
Click to expand...
There are several ways around this, assuming you don't want to actually refactor.
For example you could put the code inside the procedure in a .if Include and just use the include in the procedure.
 
andre42 said:
There are several ways around this, assuming you don't want to actually refactor.
For example you could put the code inside the procedure in a .if Include and just use the include in the procedure.
Click to expand...
Yes It could the solution. About this, is an include file more suitable than a class file ?

Maybe a more hystorical fact about what I'm doing could help us.

We have a big app for organising our production flow that as everything writen inside for arround 10000 lines. At the first it was made for only one language (French), but now we have users arround the world and we have to make our app translatable in other languages. So I checked every line to apply the << :U >> and so I make some procedure much bigger and now they aren't editable by the app builder and only with the procedure editor.

I think an other project would be to upgrade the code to make it more suitable and easyer to understand.
 
BobyIsProgress said:
So I checked every line to apply the << :U >> and so I make some procedure much bigger and now they aren't editable by the app builder and only with the procedure editor.
Click to expand...
BobyIsProgress said:
(BTW OE10.2B)
Click to expand...
Another factor you should be considering to appeal to your users around the world is that new sales will become more challenging with a solution that uses a retired OpenEdge release from 2009, which means that it no longer receives bug fixes or security fixes and is no longer certified to run on current and upcoming operating system releases.

If I were you I would plan a migration to 12.x or 11.7; which one is appropriate for you as a first step depends on your platform needs and the list of de-supported features in 12.0. Notably, in your case, this includes the OpenEdge Translation Manager, though recently Progress has expressed the intent to open-source the tool so it can still be used and maintained by the community. If you use App Server or WebSpeed, this would also argue in favour of moving to 11.7 as a first step so you can then refactor your application to work with PASOE, which would then allow a future upgrade to 12.x.

As a side-benefit of either upgrade path, you could start using Progress Developer Studio (PDSOE), the new Eclipse-based IDE, and not have to deal with the file-size limitations that are now making you jump through hoops.
 
A procedure that is 10000 lines wrong is a problem in and of itself. You can be quite certain that it contains many more than just one bug.

I understand that it is something that you have inherited. But you really ought to whittle it down to size as a soon as you possibly can.

Also, 10.2B is ancient. obsolete and unsupported. You should upgrade.
 
I can only second Tom's opinion. Fiddling around with such code without refactoring it will likely introduce new problems. Refactoring, IMHO, is an engineering practice that is not applied enough. Most developers I met through my career actually didn't own they code they produced - just pushing out new features as fast as possible thus introducing an enormous amount of technical debt into the code base.

That does not mean that you need to refactor the whole code base you've inherited - you can't. Take ownership of the piece of code you need to touch and make it better. It will make you a better professional developer and - evenly important - on a personal level you will take pride in what you achieved.
 
I can only second you both on this matters. But for the time I have left for this project I can't afford to refactoring it. But It's somewhere in my head loud and clear.

Also After the end of this project, we have planned to upgrade our ERP version and so upgrade Openedge version at least to 11.7 and i hope newer :)
 
You must log in or register to reply here.
Back
Top