Inherited code checking Struts method name I am working in an inherited code (as in "everybody related to it left before I arrived at the job and left no documentation") and I have noticed an strange pattern.

Almost(*) each Struts (Struts 1.3.8) method that is invoked begins with a code such as

public ActionForward myMethod(ActionMapping mapping, ActionForm form,
  HttpServletRequest request, HttpServletResponse response)
    throws IOException, SerletException {

  String method = request.getParameter("method");
  if (method != null &amp;&amp; "myMethod".equals(method)) {
    // Perform the actual work
    ...


I mean, I would be pretty confident that Struts would redirect each request to its associated method and I should not need to double-check it in the logic (also, if Struts fails to properly redirect, then the application would fail because the desired operation would not be executed).

I have asked Google for reasons for this code (existing or old bugs, etc.) but found none; anyone with experience in Struts can provide a reason that justifies the existence of such a code and so much (apparently) wasted effort? I want to know if I am free to delete such code to simplify the methods (which are messy enough without these "improvements").

(*) There are a few instances in which the code does not appear, but it smells just of the programmer forgetting it.
I don't believe there's any good use-case for this code.  I know it makes for a boring answer, but sometimes the correct thing really is simple and boring.  As you say, the Struts framework should always redirect to the appropriate method and fail entirely otherwise.

Even the scant lines you posted have some bad/useless programming practices, so my guess is that the developer thought he was being thorough and clever by tacking on needless framework.

if (method != null &amp;&amp; "myMethod".equals(method)) {
    // Perform the actual work


He already checks for method != null and then checks for "myMethod".equals(method).  The only reason to use the second construction for a String comparison is to avoid a NullPointerException... which he's already done by checking against null.  So either he doesn't know that Java short-circuits conditions, or he has no idea what the purpose is behind the second construction.

Also, it's generally a bad idea to have huge wrappers around entire method bodies.  It would be a better design to have something like this (if it were needed at all):

if(method == null || !method.equals("myMethod") {
    return;
}

//do stuff


... Or you could write the conditional as if(!"myMethod".equals(method)), but I honestly really hate the flipped comparison rather than explicitly checking for null.  I suppose it's a matter of taste, though.

Anyway, bottom line: no, there's no use for it, and there's evidence that the original programmer didn't entirely know what he was doing, anyway.