When writing GObjects it’s usually a good idea to follow same naming conventions. It not only makes your code easier to follow but makes easy to automatically catch some semantic errors otherwise easily overlooked.
Long time ago I wrote a two-part script which (ab)uses perl and cpp to extract calls to g_object_class_install_property() and g_signal_new() and checking the parameters follow a consistent pattern. For example:
g_object_class_install_property (object_class, PROP_MIN_POSITION, g_param_spec_int ("min_position", P_("Minimal Position"), P_("Smallest possible value for the \"position\" property"), 0, G_MAXINT, 0, G_PARAM_READABLE)); ... g_object_class_install_property (object_class, PROP_MIN_POSITION, g_param_spec_int ("max_position", P_("Maximal Position"), P_("Largest possible value for the \"position\" property"), 0, G_MAXINT, G_MAXINT, G_PARAM_READABLE));
When creating new signals it’s even easier to make copypaste errors and forget to rename one of the parameters since there are more:
signals [CYCLE_CHILD_FOCUS] = g_signal_new ("cycle_child_focus", G_TYPE_FROM_CLASS (object_class), G_SIGNAL_RUN_LAST | G_SIGNAL_ACTION, G_STRUCT_OFFSET (GtkPanedClass, cycle_handle_focus), NULL, NULL, _gtk_marshal_BOOLEAN__BOOLEAN, G_TYPE_BOOLEAN, 1, G_TYPE_BOOLEAN);
Recently crispin took both pieces and combined them into easier to use, single two-in-one, script object_check.pl. It checks the function parameters and prints them out if they don’t match naming conventions. Of course if you’re using your own naming conventions the tool won’t be as useful, it’ll print all false positives then.
Apparently there were such bugs in Galeon (again? I thought we caught them the last time.) No such bugs in Epiphany. Damn.