Some people don't seem to understand why visual component prefixes are used.... lmddckpnlSales has advsbtnFilter and lmdfrmdsplySaleEdit on it. If we have to have them can they at least be shorter than the name of the component?

Some people don't seem to understand why visual component prefixes are used.... lmddckpnlSales has advsbtnFilter and lmdfrmdsplySaleEdit on it. If we have to have them can they at least be shorter than the name of the component?

Really, I don't care that the button in question is a TMS one, or that it's the "s" variant, I just care that it's a button. And most of the time I care more about what other controls it's with, or what it's for, than I care about what sort of control it is.

I'm a fan of the "purpose first" naming so things sort together:

  SaleDiscountButton: TAMSFunkyGraphicButton;
  SaleDiscountPercentageEdit: TJEDIPercentNumericEdit;
  SaleDiscountFixedAmountEdit: TFredsFunControlsCurrencyEdit;
  SaleDiscountDescriptionEdit: TOverdesignedEditControl;

That way when you see SaleDiscountDescriptionEditOnMenuPopup(nil); in code you're not in any doubt as to what it is, and you can probably guess what the method does. But advgradspdbutnFilter? Yeah, great, I need to change that to a TMS control because now we have animations... and rename every mention of it... it still does exactly the same thing, just now it's a different sort of button.

Comments

  1. Iman Crawford me too, when I can. But following the existing coding standard is (much) more important, and I am dealing with a lot of code. Extending it rather than adding big new chunks, otherwise I'd be tempted to switch. What I am doing is "refactoring" s I go by creating shared units rather than copy-paste-modify. Which seems to be acceptable to the coworkers.

    Little wins :)

    ReplyDelete
  2. Anyone remember the Delphi Prefix Registry?

    ReplyDelete

  3. Moz Le agreed. Staying with the existing code style is important.

    ReplyDelete

Post a Comment