Why we deliberately stick to the FiveWin style When migrating from FiveWin/Harbour to web technologies, you quickly run into modern naming conventions: openDeleteModal() handleConfirm() cleanupOnClose() They are “state of the art” — but not automatically state of clarity. Especially in business software, it becomes clear that: readability and mental familiarity matter more than fashionable syntax. Comparison Modern web conventions openDeleteModal() closeDeleteModal() confirmDelete() handleAbort() cleanupOnEscape() Characteristics: technically correct framework-oriented often generic meaning only emerges from context strongly shaped by training data and common patterns FiveWin style (deliberately chosen) mdDEL_Open() mdDEL_Close() mdDEL_Confirm() mdDEL_Abort() mdDEL_Cleanup() Characteristics: dialog-oriented rather than event-oriented clear mental reference to Dlg, ACTIVATE, END each function describes a user decision immediately readable — even months later no context needed to understand the effect Why the FiveWin style makes sense in a business environment Domain logic beats technical logic The user confirms, aborts, or closes — nothing is “handled” or “cleaned up”. Migration without a mental break The code feels familiar, even though the platform is new. Maintainability > elegance Better clear and predictable than “modern” and in need of explanation. Dialogs are states, not events That’s exactly how they were conceived in FiveWin — and that’s exactly how they work on the web as well. Conclusion Modern naming is not wrong. But for business software with a long lifespan, the FiveWin style is often: more understandable, more stable, and more maintainable. Not everything that is new is automatically better — some things are simply more familiar and clearer.
This is a well-articulated perspective on naming conventions. A few thoughts to add to the discussion:
Where the FiveWin style shines:
- Discoverability: mdDEL_* groups everything related to that dialog alphabetically in any IDE — huge for maintenance
- Searchability: Grep for mdDEL_ and you get the entire dialog surface area instantly
- Migration fidelity: Developers moving from FiveWin don't need to mentally map "event handlers" back to "dialog actions"
Where modern conventions have a point:
- Framework integration: React/Vue/Svelte ecosystems expect handleX, onX patterns for automatic wiring
- Testing: handleConfirm maps cleanly to unit test names (it('handles confirm...'))
- Event-driven architectures: When dialogs are truly event-sourced, "handle" reflects the reality
Pragmatic middle ground I've seen work:
// Module: mdDelete.js
export const mdDEL = {
open: () => { /* ... */ },
close: () => { /* ... */ },
confirm: () => { /* ... */ },
abort: () => { /* ... */ },
cleanup: () => { /* ... */ },
};
// Framework adapter layer (React example)
export const useMdDelete = () => ({
onOpen: mdDEL.open,
onClose: mdDEL.close,
onConfirm: mdDEL.confirm,
onAbort: mdDEL.abort,
});
Keeps the domain-oriented core (FiveWin style) while exposing framework-friendly hooks at the boundary. Best of both worlds for migration projects.
Question for you: Are you currently migrating a FiveWin codebase to a specific web stack (React, Vue, plain JS, mod_harbour + HTML5, etc.)? The adapter approach above works differently depending on the target.
Respuesta generada por Inteligencia Artificial usando el modelo nemotron-3-ultra-free via OpenCode Zen. Puede contener errores; por favor verifiquela antes de aplicar.
AI-generated reply using the nemotron-3-ultra-free model via OpenCode Zen. May contain mistakes; please verify before applying.