Forums

Annoying or amusing code isn't just limited to those that use Jade on a day to day basis - how about the Jade internals themselves? For example:

Why are controls that are added to forms in the painter made public? It makes little sense to me and breaks one of the cardinal rules of data encapsulation. At the least we should be able to change this.

And one that may be more controversial: why "color" and not the correct "colour"? "initialize" instead of "initialise"? (I'm being a bit tongue in cheek here, I don't think this is a big deal).

I posted a contact on Parsys where doing a File::peek(len), where len was 0, would cause an unhandled exception.
Jade's response was that this was not an issue, in fact I think it hadn't been documented yet.

I still cannot understand why the function does not just return zero bytes like most other languages seem to do.
Seems a bit over the top to generate an exception.

or the username and password popup when you go to the Jade Monitor from inside Jade when you have already logged in!...

I don't like making anything protected - just a waste of time in my opinion

I don't like making anything protected - just a waste of time in my opinion

I find it quite useful to know that nothing external is using a property or method. It can help with locking strategies, and in particular lets you develop classes/structures that are "black boxes" which makes them easier to unit test and more consistent when using an agent/controller layer. By default everything I add is protected. Read-only is an exception and public is "never". Which is why public control properties on forms is annoying for a purist like me.

I'm with Allistar on this one. I once had to maintain a wizard style interface implemented as 3 separate forms. Each form set or read internal properties on the other two. Made it a nightmare to actually figure out what was going on. We enforce a "One public method to display a form" rule here and would be making control properties hidden if that was available

Hopefully this won't turn into a coding style war, but I'm also with Allistar & Torrie on this one. My IDE defaults are protected for properties & methods and as I find methods that are internal to a class that were not marked as protected by others on my team, I'll "fix" the methods and remind the developer the default position is protected until there is a justifiable reason to change this setting, and then the properties will only become read-only.

We do, however, have a general exception to this rule. Our proxy objects for our transaction agents have all public properties to avoid the need for very long "populateProxy" methods with lots of parameters.

Cheers,
BeeJay.