Share This!

Thursday, May 25, 2017

Naming Conventions

50% plus of the grief I have with software - especially Microsoft software - comes from when things are named inconsistently.  If you're going to pop a message to a developer - or user - that says:

Missing reference to Microsoft.SqlServer.Types

That what needs to happen is adding something named Microsoft.SqlServer.Types to someplace called References. I see this all the time.  Different apps call the config screen Config, Settings, Options, or Preferences.  Some apps have more than one of these.  So when you pop a message that says:
Unable to connect: check URL in settings
And your app only has Options, not settings, and the URL you are looking for is labelled "Address", not "URL", you leave your users confused and unsure what your messages mean.

The right way to design, is with consistency and uniformity.  I tend to call web pages "Page" and WinForms, "Forms".  Imagine this menu:
Notice how some reports are called "Report", some are called "Summary", some are called "Form", Some are called "Screen".  Note that the capitalization is inconsistent.  Note that the last two reports could be the same thing, who knows what the difference is until you generate the reports.

This all looks unprofessional.

If you're going to call something an "Options Form", make sure that every single place it's referenced it is called that. This includes:
  • Menus
  • Title Bars
  • Help Files
  • Emails to the client.
  • Support Phone Calls
  • Support Emails
  • Forum Posts
  • Help Tickets
  • Agile Sprints
  • Release Notes
  • Ads and Website References
  • Knowledge-base Article
  • Any employee tattoos that reference the app.
If you're calling Winforms "forms", then use that throughout.  If you're calling them "screens", then use that.  Even if your user says "Hey I was looking at the inventory page and I found a bug", your support people should answer in the format "Show us where on the inventory form you encountered this..."


Bryan Valencia is a contributing editor and founder of Visual Studio Journey.  He owns and operates Software Services, a web design and hosting company in Manteca, California.

Friday, May 5, 2017

How to Check for any Changes in Table Data.

I am having a problem where some sneak process is changing the wrong
data in my inventory table. I wanted to discover how and when this was
happening, so I created a copy of my inventory table (on my local
machine, like this:
Select * from [dbo].[Inventory] into [dbo].[InventoryBASELINE]
Now I can check for discrepancies, like this...
select * from [dbo].[InventoryBASELINE] IB where CHECKSUM(*) <>
isnull((select CHECKSUM(*) from [dbo].[Inventory] I where IB.ID=I.ID),0)
union all
select * from [dbo].[Inventory] I where CHECKSUM(*) <> isnull((select
CHECKSUM(*) from [dbo].[InventoryBASELINE] IB where IB.ID=I.ID),0)
order by ID

This will show me any rows that are different, missing, or added between
my baseline table and my current table.
If I only cared about a few columns, I could use CHECKSUM(Customer, Qty,
Style) any columns I care about in all 4 checksum functions.

Contact Us


Email *

Message *