..in mankind that is. Well at least in developer-kind. After Friday's travails with that awful code, I was beginning to think it was impossible to pick up someone else's code and run with it. Well, today I was messing around with expression parsing and evaluation, and asked a question on stack overflow regarding the subject. One of the answers was from Barry Kelly, who works for Codegear on the compiler team. (maybe he IS the compiler team, I don't know) More often than not, it's Barry who answers my questions, I don't know why I don't just ask him for his phone number. Anyway, he pointed me in the direction of the Jedi Code Library and more specifically the JclExprEval unit. Apparently he wrote this a few years ago. It's everything that the code I was struggling with on Friday was not. It's will written, simple to read and understand, even though there is no documentation. Very easy to use, and should I ever need to debug it, I'm sure I'd have no problems. I can understand exactly what the developer had in mind, and can use it as is, or take away what I need with very little effort.
It's not always easy to describe what makes good code and what makes bad code. The thing is though, you always know good code from bad as soon as you see it. You also can tell so much about the developer who wrote it even though you've never met him or her.
Posts
5 comments:
The only problem with JEDI is that the units are often interdependent, which makes it difficult to use only one unit.
@compaspascal: Isn't the the problem with every library/framework. The developers don't want to write duplicate code, so they use already written code by using the unit where the code was already written.
Sorry to just "pop in" as it were (and I'm not the only member of the compiler team - there are at least 3 others currently, depending on how you count the overlaps), but JclExprEval is actually documented. When I originally wrote it, JEDI were using DocOMatic, but in separate documentation files rather than inline in the source. I didn't know that, though, so I put all my documentation inline in the source. It appears it was consolidated later, to be like the others.
The documentation is in the same help format as the others, and is available for download on the JCL sourceforge site. Here's a link to the chm version:
http://downloads.sourceforge.net/jcl/jcl-1.104.1.3248-chmhelp.zip?use_mirror=ovh
i think the biggest problem with jedi is it's not (very well) documented. It's often easier to write your own function/component for something than try to find it from Jedi.
A good library gives the programmer a good overview of what it does, how it does it, and dependencies.
It's not fun to include a bunch of units, just to find out later that one of them introduces a dependency to a DLL that is not acceptable.
Last time I had to use something from JEDI, I found the information about the functionality in a forum, I spent too much time on figuring out how it worked, and had to spend time on separating the desired functionality from the rest of JEDI. After some testing, I concluded that it was too slow and started from scratch, writing my own unit.
I guess JEDI is best at quick & dirty solutions.
Post a Comment