Wayback Machinekoobas.hobune.stream
May JUN Jul
Previous capture 13 Next capture
2021 2022 2023
1 capture
13 Jun 22 - 13 Jun 22
sparklines
Close Help
  • Products
  • Solutions
  • Made with Unity
  • Learning
  • Support & Services
  • Community
  • Asset Store
  • Get Unity

UNITY ACCOUNT

You need a Unity Account to shop in the Online and Asset Stores, participate in the Unity Community and manage your license portfolio. Login Create account
  • Blog
  • Forums
  • Answers
  • Evangelists
  • User Groups
  • Beta Program
  • Advisory Panel

Navigation

  • Home
  • Products
  • Solutions
  • Made with Unity
  • Learning
  • Support & Services
  • Community
    • Blog
    • Forums
    • Answers
    • Evangelists
    • User Groups
    • Beta Program
    • Advisory Panel

Unity account

You need a Unity Account to shop in the Online and Asset Stores, participate in the Unity Community and manage your license portfolio. Login Create account

Language

  • Chinese
  • Spanish
  • Japanese
  • Korean
  • Portuguese
  • Ask a question
  • Spaces
    • Default
    • Help Room
    • META
    • Moderators
    • Topics
    • Questions
    • Users
    • Badges
  • Home /
avatar image
0
Question by Abelabumba · Feb 03, 2015 at 08:40 AM · buttonbeginnerscriptingbasicsif-statements

Which is better, lots of if-statements or seperate button scripts?

So I'm working on a minigame that is entirely UI driven, I use buttons with gameObject.SetActive to show and hide different menus. Currently those buttons all use the same ButtonScript with

 public void OnClick(string text)
     {       
         if (text == "toSub")
         {
             mainMenu.gameObject.SetActive(false);
             subMenu.gameObject.SetActive(true);
         }
         if (text == "toMain")
         {
             mainMenu.gameObject.SetActive(true);
             subMenu.gameObject.SetActive(false);
         }

and so on, which works. I'm just wondering if (and why) it would be better to have seperate button scripts, one for toMain, one for toSub and so on. It's not a giant list or something, will probably cap at 10 or less.

I have seperate scripts for buttons that do completely different things like adding/substracting values etc - would it make sense to put those into the above one single button script with their own ifs, too? I'm tending towards "no", but just for readability reasons.

Bonus question, I feel I should do else if instead of just if on the 2nd+ cases, but I don't see any difference in behaviour, is there one?

Comment
Add comment
10 |3000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users

1 Reply

· Add your reply
  • Sort: 
avatar image
1
Best Answer

Answer by CHPedersen · Feb 03, 2015 at 09:04 AM

It's better to have separate methods for separate button events. :) By the way, it's good that you even think about this stuff - curiosity about these things is what makes a great programmer in the end.

The reason why is found in readability and in performance. For readability and structure, methods should concentrate on doing as few things as possible instead of trying to be catch-alls. When they grow in size, the latter design becomes an antipattern because it grows error-prone.

As for performance, you'd be interested in not having the CPU evaluate conditionals to figure out which button was pressed and therefore, what code to execute. You'd ideally have separate OnClick methods, one for each button, like so:

 public void ToMain_OnClick()
 {
 }
 
 public void ToSub_OnClick()
 {
 }
 
 ... etc

As for the final bonus question, you're perfectly right - in any case where multiple, mutually exclusive conditionals must belong in the same structure, you should always go for if-else if. The reason is that when the condition is mutually exclusive, there is no reason for the CPU to have to evaluate all of the following conditions too.

In your example above, if the input string is equal to "toSub", it cannot at the same time also be equal to "toMain". So if the CPU has already evaluated that it's "toSub" and executed that code, it's a waste of time to also test to see if it's "toMain". "else if" avoids that.

Comment
Add comment · Show 1 · Share
10 |3000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users
avatar image Abelabumba · Feb 03, 2015 at 09:10 AM 0
Share

Thanks for your detailed answer.

Your answer

Hint: You can notify a user about this post by typing @username

Up to 2 attachments (including images) can be used with a maximum of 524.3 kB each and 1.0 MB total.

Follow this Question

Answers Answers and Comments

20 People are following this question.

avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image

Related Questions

UI element moves down when another UI elements gets too close? 0 Answers

Calling method once 2 Answers

Hide Objects on Higher Plane 0 Answers

Android 3D Touch for Menu 0 Answers

Making a turret shoot at a low fire rate. 2 Answers


Enterprise
Social Q&A

Social
Subscribe on YouTube social-youtube Follow on LinkedIn social-linkedin Follow on Twitter social-twitter Follow on Facebook social-facebook Follow on Instagram social-instagram

Footer

  • Purchase
    • Products
    • Subscription
    • Asset Store
    • Unity Gear
    • Resellers
  • Education
    • Students
    • Educators
    • Certification
    • Learn
    • Center of Excellence
  • Download
    • Unity
    • Beta Program
  • Unity Labs
    • Labs
    • Publications
  • Resources
    • Learn platform
    • Community
    • Documentation
    • Unity QA
    • FAQ
    • Services Status
    • Connect
  • About Unity
    • About Us
    • Blog
    • Events
    • Careers
    • Contact
    • Press
    • Partners
    • Affiliates
    • Security
Copyright © 2020 Unity Technologies
  • Legal
  • Privacy Policy
  • Cookies
  • Do Not Sell My Personal Information
  • Cookies Settings
"Unity", Unity logos, and other Unity trademarks are trademarks or registered trademarks of Unity Technologies or its affiliates in the U.S. and elsewhere (more info here). Other names or brands are trademarks of their respective owners.
  • Anonymous
  • Sign in
  • Create
  • Ask a question
  • Spaces
  • Default
  • Help Room
  • META
  • Moderators
  • Explore
  • Topics
  • Questions
  • Users
  • Badges