I'm currently scratching my head over how to refactor a method that basically only builds the UI.

The method is more than 1500 lines of code (LOC) long - and counting. It has grown, there was no plan how to approach this. You might find this familiar.

Anyway, it's basically just one large method that goes a little something like this:


    # null checks
    null_checks_bx = Box(True)

    null_checks_ck = CheckBox()
    null_checks_ck.set_text('Null checks throwing exceptions of type:')

    if 'doNullChecks' in options:

    # dict to sorted list: extract values from dict by list comprehension
    exceptions = sorted([exception.get_full_name() for exception in JavaTypes.exception_types])

    null_checks_se = Selector()

    if 'nullChecksExceptionFullClassName' in options:
        # default to first entry
        #(defaulting to doEquals = True and doHashCode = True by using hardcoded Commons Lang implies availability of Commons Lang NullArgumentException)

    # callback
    Callbacks.sync_model_active_status(null_checks_ck, null_checks_se)

    null_checks_ck.add_clicked_callback(lambda: Callbacks.sync_model_active_status(null_checks_ck, null_checks_se))

    null_checks_bx.add(Label(indent), False, True)  # dummy indent label
    null_checks_bx.add(null_checks_ck, False, True)
    null_checks_bx.add(null_checks_se, False, True)

    # relationship entity class constructor calls
    relationship_constructor_calls_bx = Box(True)

    relationship_constructor_calls_ck = CheckBox()
    relationship_constructor_calls_ck.set_text('Instantiate relationship entities (if all necessary columns present)')

    if 'doRelationshipConCalls' in options:

    relationship_constructor_calls_bx.add(Label(indent), False, True)  # dummy indent label
    relationship_constructor_calls_bx.add(relationship_constructor_calls_ck, False, True)

    # relationship not-null checks: this is an option independent of the null checks!
    relationship_not_null_checks = Box(True)

    relationship_not_null_checks_ck = CheckBox()
    relationship_not_null_checks_ck.set_text('Not-null checks before relationship instantiation')

    relationship_not_null_checks_ck.set_enabled(relationship_constructor_calls_ck.get_active() and not null_checks_ck.get_active())

    if 'doRelationshipNotNullChecks' in options:

    # callback
    Callbacks.sync_convenience_constructor_options(null_checks_ck, relationship_constructor_calls_ck, relationship_not_null_checks_ck)

    null_checks_ck.add_clicked_callback(lambda: Callbacks.sync_convenience_constructor_options(null_checks_ck, relationship_constructor_calls_ck, relationship_not_null_checks_ck))
    relationship_constructor_calls_ck.add_clicked_callback(lambda: Callbacks.sync_convenience_constructor_options(null_checks_ck, relationship_constructor_calls_ck, relationship_not_null_checks_ck))

    relationship_not_null_checks.add(Label(indent), False, True)  # dummy indent label
    relationship_not_null_checks.add(Label(indent), False, True)  # dummy indent label
    relationship_not_null_checks.add(relationship_not_null_checks_ck, False, True)

    # build final box
    checks_bx = Box(False)
    checks_bx.add(omit_auto_increment_columns_bx, False, True)
    checks_bx.add(omit_auto_timestamp_columns_bx, False, True)
    checks_bx.add(null_checks_bx, False, True)
    checks_bx.add(relationship_constructor_calls_bx, False, True)
    checks_bx.add(relationship_not_null_checks, False, True)

    # callback
    Callbacks.sync_model_active_status(convenience_constructors_ck, checks_bx)

    convenience_constructors_ck.add_clicked_callback(lambda: Callbacks.sync_model_active_status(convenience_constructors_ck, checks_bx))

    # need wrapped box for Panel class
    constructors_bx = Box(False)
    constructors_bx.add(convenience_constructors_bx, False, True)
    constructors_bx.add(checks_bx, False, True)

    constructors_pn = Panel(TitledGroupPanel)

    # getters and setters
    is_conversion_bx = Box(True)

    is_conversion_ck = CheckBox()
    is_conversion_ck.set_text('Convert respective column names starting with "is_"')
    is_conversion_ck.set_tooltip("Column is_incognito => getter isIncognito() (not getIsIncognito()) and setter setIncognito()")

    if 'doIsConversion' in options:

    is_conversion_bx.add(is_conversion_ck, False, True)

    # generate code for relationship getters and setters to synchronize with column fields
    sync_relationship_pk_fields_bx = Box(True)

    sync_relationship_pk_fields = CheckBox()


You get the point.

What I don't see is what the criteria might be to split this method up so the code will become more managable, more understandable etc pp.

What are the best practices here?

I could create some methods that would create recurring types of panels and widgets, but this would become a rather tedious effort for what I fail to see the real gain.

Again, what are some useful, practical approaches to large, clumsy methods that only build the graphical UI?


PS: oh and BTW the UI is a single Dialog in a standard, windowed application (no web), and this dialog has 6 tabs which contain mostly check boxes, radio buttons, and text boxes. It is a code generation plugin that the user can choose a lot of options from. I might post an image as soon as I get the plugin running again...

  • One thing I'd change is separating the static setup from the dynamic state. – CodesInChaos May 24 '14 at 12:20
  • @Kawu you can also accept the answer if it solves your problem and answers the question in a comprehensive way. – toniedzwiedz May 25 '14 at 8:08
  • Yea of course. I'm not an SO beginner. It's just that it's hard to beat the accepted answer. – Kawu May 25 '14 at 10:07

Your code appears to have one feature you can use to your advantage here: all those grouping comments. You can use those comments as the basis for breaking up the method into chunks by extracting smaller methods. You pull out each chunk into its own method, then call that method from the code's original location.

As you start to pull these pieces out, you will either naturally find duplication or you will naturally find strong relationships between some of the methods. As you find duplication, you extract that into helper methods to DRY out your code. As you find natural relationship boundaries, you can break those off into separate classes of more closely related functionality.

Below, for example, I've started to pull out the logic for building the null checks portion. I've extracted it as a method, broken out a few pieces that needed a better name, and de-namespaced all the variables within the method. There's a lot more that can be done, but that is left as an exercise for the reader.

def add_indent_label(self, box):
    box.add(Label(indent), False, True)

def get_null_checks(self, options):
    box = Box(True)

    checkbox = CheckBox()
    checkbox.set_text('Null checks throwing exceptions of type:')

    if 'doNullChecks' in options:

    exceptions = self.get_exceptions()

    selector = Selector()

    if 'nullChecksExceptionFullClassName' in options:

    # callback
    Callbacks.sync_model_active_status(checkbox, selector)
    checkbox.add_clicked_callback(lambda: Callbacks.sync_model_active_status(checkbox, selector))

    box.add(checkbox, False, True)
    box.add(selector, False, True)

    return box

def get_exceptions(self):
    return sorted([exception.get_full_name() for exception in JavaTypes.exception_types])

# This could probably have a better name
def get_first_exception(self):
    #(defaulting to doEquals = True and doHashCode = True by using hardcoded Commons Lang implies availability of Commons Lang NullArgumentException)
    return JavaTypes.exception_types[0].get_full_name()

And in your original code, it becomes:

null_checks_bx = self.get_null_checks(options)

Not the answer you're looking for? Browse other questions tagged or ask your own question.