Method Naming Convention Question (most languages)
If I have a method that hides a button, I would probably call it HideButton
If I have a method that shows a button, I would probably call it ShowButtonBut what do you guys call a ShowIfThisHideIfThat style method?
Possible Choices:
TestForButtonVisibility (this kind of sounds like it will return true/false but not actually do the work) TestButton ShowHideButton (style I'm currently using)Been at this a number of years and still don't have a style that I like for these types of methods. I'm workin开发者_开发知识库g mostly in C# and a little Java, Ruby, and F#. What do you use for method names in this regard?
// example of the style of method
public void ShouldIShowOrHideButton()
{
Button.Visible = ((chkSomeSetting.Checked) && (DateTime.Now.Day < 8));
}
How about updateButtonVisibilty()
?
Might be overengineering, but the reason you may have problems because it's doing two things. So making sure you only have a function doing a single thing, howabout a method to determine if the button should be shown or not (takes parameters, returns bool), then set the value of the button directly.
Button.Visibilty = DetermineIfButtonShouldBeShow(...);
My preference has been to keep toggle methods rather than separate methods for hide/show.
ToggleButtonVisibility()
This allows you to put your testing code in there and the expected result/output would be a properly visible/invisible button.
Edit: Toggle is a personal preference that stems from a partial background in working with binary gates, architecture, etc where a toggle may go through several separate gates before reaching an end state. The word itself could be changed to anything else such as Update, Determine, Finalize, or even Steve. It really boils down to what makes sense to you and what your standard is.
Edit: Now your question is edited to include the example
// example of the style of method
public void ShouldIShowOrHideButton()
{
Button.Visible = ((chkSomeSetting.Checked) && (DateTime.Now.Day < 8));
}
My answer is neither. I would do two things:
- Move the
Button.Visible
part outside the function, so the function just computes the logic and returnsbool
. - Name the function according to its internal logic not according to whether it is for a button or not. So if your function checks for a wedding day it would be called
IsWeddingDay
, if it checks for a monthly meeting it would beIsMonthlyMeeting
.
The code would be
Button.Visible = IsMonthlyMeeting()
and the logic can be subsequently used to control any other widgets if needed.
Old Answer: You probably need to explain more what ShowIfThisHideIfThat does.
If it depends on one condition, like:
if (condition)
ShowBotton()
else
HideButton()
then I would use
Button.SetVisibility(condition)
as per Lazarenko's comment above, or if the language has properties:
Button.Visible = condition
If you have two conditions like what ShowIfThisHideIfThat seems to imply, equivalent to:
if (cond1)
ShowButton()
else if (cond2)
HideButton()
else
LeaveButtonAsItIs()
then the logic in my opinion is complicated and I wouldn't use one function. Sure, the code is equivalent to
Button.Visible = cond1 || (!cond2 && Button.Visible)
but you lose the understandability.
I would use one of these:
- setXVisibility
- refreshX or refreshXStatus
How about using SetButtonVisibility( )
The confusion seems to stem from a mixing of the business logic and the UI logic. The test isn't whether the button should be shown. Code is going to use the test to decide if the button should be shown. It probably depends on whether some feature should be available. Consider:
if (IsFeatureEnabled()) {
ShowButton();
} else {
HideButton();
}
This is the code where business logic (IsFeatureEnabled()
) meets UI (ShowButton()
/HideButton()
).
精彩评论