I started developing for ios in a new company. Here they taught me to never use iterface-builder, saying it's hard to maintenance the code and it have a few limitations.
我在一家新公司开始开发ios系统。在这里，他们教我永远不要使用iterface-builder，说维护代码很困难，并且它有一些限制。
Using interface build for java application in netbeans i see a lot of "bad code" but i don't see it using IB, besides i see a lot of IB codes on the internet and only a few codes without it.
在netbeans中使用java应用程序的接口构建时，我看到了很多“坏代码”，但是我没有看到使用IB的代码，而且我在internet上看到了很多IB代码，只有很少的代码没有它。
So for a large where no one is a beginner on ios development is a bad pratice use IB?
那么对于没有人是ios开发新手的大型应用来说，使用IB是一个糟糕的实践吗?
4 个解决方案
#1
16
(Let me mention in advance that I have strong objection against using Interface Builder, for a number of reasons I will explain)
(让我提前说明一下，我强烈反对使用接口构建器，原因如下)
Here they taught me to never use Interface Builder, saying it's hard to maintain the code and it has a few limitations.
这里他们教我永远不要使用接口构建器，说维护代码很困难，而且它有一些限制。
This is only partially true. The principal reason I don't like Interface Builder and Xcode in general is that a lot of beginner programmers think that it is the only way for developing iOS/OS X apps. They have never heard of gcc and clang, they don't know what the compiler and linker error messages mean, they can't use make, and they have no idea about what the difference between the Objective-C language, the Cocoa (Touch) APIs, the IDE and the compiler is.
这只是部分正确。我不喜欢界面构建器和Xcode的主要原因是，很多初学者认为这是开发iOS/OS X应用程序的唯一途径。他们从未听说过gcc和clang，他们不知道编译器和链接器错误消息的含义，他们不能使用make，他们也不知道Objective-C语言、Cocoa(触摸)api、IDE和编译器之间有什么区别。
After all, they start using Interface Builder and Xcode with all of its quirky and sometimes strange/illogical features (and bugs as well), but when they're in the need of developing something non-obvious, they don't even realize there is a method for, for example, creating views and view controllers programmatically (yes, I've seen this very question on *).
毕竟,他们开始使用界面构建器和Xcode的古怪,有时奇怪/不合逻辑的特性(错误),但当他们在发展中一些不明显的需要,他们甚至不知道有一个方法,例如,创建视图和视图控制器编程(是的,*我见过这个问题)。
So, when abused (or rather, used too early), Interface Builder and all of the "convenient" features lead to programmers learning bad concepts and missing some important pieces of practice and experience.
因此，当滥用(或者更确切地说，使用得太早)时，接口构建器和所有“方便”的特性会导致程序员学习糟糕的概念，并遗漏一些重要的实践和经验。
However, if you're a senior developer, who has all the necessary skills, and you feel you could write an entire application from scratch, using just a simple text editor and a Makefile, then you are by all means permitted to use IB, and even encouraged to do so if you feel that's more comfortable than hammering out code.
然而,如果你是一个高级开发人员,所有必要的技能,你觉得你可以从头开始编写整个应用程序,仅使用一个简单的文本编辑器和一个Makefile,那么你就意味着允许使用IB,甚至鼓励这样做如果你觉得更舒适比敲定代码。
So, to sum up:
所以,总结:
Using interface builder is really a bad practice?
使用接口构建器真的是一个坏习惯吗?
No. Rather abusing it and not making the effort to learn the programmatic approach to UI stuff is bad practice.
不。与其滥用它，不如不去学习UI的编程方法，这是不好的做法。
Post scriptum: I have quite a lot of experience with iOS development, but I still find Interface Builder rather inconvenient and inconsistent. I generally use code for everything. But that seems to be my personal preference. One advantage is, however, that if one creates everything by code, then another programmer without access to these Apple-specific tools will be able to contribute to the project as well. This is a point where the "it's hard to maintain" part comes true...
编剧:我在iOS开发方面有很多经验，但我仍然觉得界面构建器非常不方便和不一致。我通常对一切都使用代码。但这似乎是我个人的偏好。然而，一个优点是，如果一个人通过代码创建所有东西，那么另一个没有访问这些特定于苹果的工具的程序员也可以为这个项目做出贡献。在这一点上，“很难维持”的部分实现了……
For example, until I didn't have enough money for a Mac, I used Linux for developing iOS apps (yes, that is actually possible). I couldn't use IB and Xcode, yet I have done loads of applications and tweaks (for jailbroken iOS, of course), and that was just fine.
例如，在我没有足够的钱买Mac之前，我用Linux开发iOS应用程序(是的，这是可能的)。我不能使用IB和Xcode，但我已经做了大量的应用程序和调整(当然是针对越狱的iOS)，这很好。
Post scriptum #2: another reason for avoiding the use of IB could be the need for dynamic UIs. If you heavily rely on animations, custom UI elements, etc., it's hard to do everything in Interface Builder. Last summer, I had to rewrite a login screen of an application, and honestly, I don't know how I could have realize our designer's ideas if I had had to use Interface Builder. The UI/UX was so dynamic and it had so many ways to change that it was absolutely necessary to have fine control over each and every pixel. And that's something that code is better at than IB.
Post scriptum #2:避免使用IB的另一个原因可能是需要动态ui。如果您严重依赖动画、自定义UI元素等，那么在Interface Builder中很难实现所有的操作。去年夏天，我不得不重写一个应用程序的登录界面，老实说，我不知道如果我必须使用接口构建器，我如何才能实现我们的设计人员的想法。UI/UX是如此的动态，它有如此多的方法来改变，所以对每个像素都进行精细的控制是绝对必要的。代码比IB做得更好。
#2
7
I strongly disagree with the idea that IB is a bad practice. Interface Builder has the following advantages over code:
我坚决不同意IB是一个坏习惯的观点。与代码相比，接口构建器具有以下优点:
-
when working with complex (and even simple) graphical interfaces, IB cuts the code down to a mere fraction - for example, simply creating a button in IB takes a few seconds, whereas in code, that translates to dozens of lines, especially if the button is to be styled
当使用复杂的(甚至简单的)图形界面时，IB将代码减少到很小的一部分——例如，在IB中创建一个按钮只需要几秒钟，而在代码中，这将转换为几十行，特别是如果要对按钮进行样式化的话
-
using autoresizing masks for supporting multiple resolutions and devices is a breeze - this is important as Apple is now pushing towards resolution-independent apps
使用自动调整面具来支持多种分辨率和设备是一件轻而易举的事——这一点很重要，因为苹果目前正在推动与分辨率无关的应用
-
changing/tweaking properties of views is a matter of a few clicks rather than lines of code, especially if working with images
更改/调整视图的属性只需要几次单击，而不是几行代码，特别是在处理图像时
However, there is one disadvantage (that comes to my mind):
然而，有一个缺点(我想到了):
- it can hard to pinpoint what might be causing a graphical problem, since it will be hidden away in in the IB file than in the code
- 很难确定是什么导致了图形问题，因为它将隐藏在IB文件中，而不是代码中
#3
4
Absolutely not. Interface Builder is a really powerful way of creating UI really quickly. Especially with Storyboards it allows you to make functional apps with very little code.
绝对不是。接口构建器是一种非常强大的快速创建UI的方法。特别是故事板，它允许你用很少的代码制作功能应用程序。
The issue of it "creating bad code" is rubbish as the IB doesn't create any code. The files it creates are essentially XML files that complement the code that you write.
it“创建坏代码”的问题是垃圾，因为IB不创建任何代码。它创建的文件本质上是XML文件，可以补充您编写的代码。
Most of the apps I've developed have been mostly started on IB.
我开发的大多数应用都是在IB上开发的。
Obviously, you can't do the FUNCTIONAL stuff of your app. I.e. you can't tell a button exactly what to do. But you can point it to a function that you have written and get a working button with almost no code.
显然，你不能做你的应用程序的功能，也就是说，你不能确切地告诉一个按钮该做什么。但是您可以将它指向您已经编写的函数，并获得一个几乎没有代码的工作按钮。
Most of the UI in iPhoto on iPad and iPhone is written in Interface Builder.
iPad和iPhone上iPhoto中的大部分UI都是用Interface Builder编写的。
#4
3
Much has been said, but I am still going to give my 2 cents for this discussion...
已经说了很多，但是我还是要为这次讨论贡献我的2分。
Until some point I agree with H2CO3, it's better to understand what's going under the hood, than keep using shortcuts to achieve something. That works most of the time, the thing, and that's where I strongly disagree with H2CO3, is the following:
在某种程度上，我同意H2CO3的观点之前，最好先了解它背后的情况，而不是一直使用快捷键来实现某些目标。这在大多数情况下都有效，我强烈反对H2CO3，是这样的:
-
Most of the people that use a technology (C#, Java, HTML, iOS, etc), they use it because their Company needs them to use it, because someone else is actually going to pay you to work with that. And not because you actually woke up in the middle of the night and suddenly had the urge to learn C.
大多数使用技术(c#、Java、HTML、iOS等)的人使用它，是因为他们的公司需要他们使用它，因为其他人会付钱给你来使用它。不是因为你半夜醒来突然有学习C的冲动。
-
If someone asks you tomorrow to create an iOS App and you never developed for iOS before, I truly doubt you are going to create an App from scratch without using XIB's or Storyboards (Which I hate btw).
如果明天有人让你创建一个iOS应用程序，而你以前从未为iOS开发过，我真的怀疑你是否会在不使用XIB或Storyboards(我讨厌它)的情况下从零开始创建一个应用程序。
What H2CO3 proposes is a utopia... Where you really understand what is going on beneath, but because you are such a "leet", you are able to use shortcuts, like XIBs. Well, things don't work that way, and sooner or later you will have to do some shitty thing to deliver something on the next morning.
H2CO3提出的是一个乌托邦……当你真正理解下面发生了什么，但是因为你是一个“leet”，你可以使用快捷方式，如XIBs。好吧，事情不是那样的，你迟早要做一些该死的事情才能在第二天早上交付一些东西。
I prefer, and that's personal perspective, to use a XIB, than to use the first 3rd party library that comes in front of me. And I think that's more reasonable than doing an interface by hand. I prefer to understand the code, and do it by myself, than using for instance a library to help me download/upload stuff.
我更喜欢使用XIB，这是我个人的观点，而不是使用前面的第一个第三方库。我认为这比手工操作界面更合理。我更喜欢自己理解代码，而不是使用一个库来帮助我下载/上传东西。
For wrapping this up, my advise to the person that asked this is:
最后，我的建议是:
Try to understand why things are done the way they are. Above all, try to be a better programmer in each new project that you face. If something new comes up (new iOS version) spend a day or two to see what's new, and what could you use. XIB's are perfectly fine to be used, but spend some time creating UIView's by hand, so you can see all the flexibility they give you. And above all, run away from Storyboards (^^)
试着去理解为什么事情是这样做的。最重要的是，在你所面对的每一个新项目中努力成为一个更好的程序员。如果有新东西出现(新的iOS版本)，花一两天时间看看有什么新东西，你可以用什么。使用XIB是完全可以的，但是要花一些时间手工创建UIView，这样您就可以看到它们给您的所有灵活性。最重要的是,逃离故事板(^ ^)
P.S: A senior developer it's not just a guy that has a "better Kung fu than you".. It's more than that.
P。S:高级开发人员不只是一个“功夫比你强”的人。它是更多。
#1
16
(Let me mention in advance that I have strong objection against using Interface Builder, for a number of reasons I will explain)
(让我提前说明一下，我强烈反对使用接口构建器，原因如下)
Here they taught me to never use Interface Builder, saying it's hard to maintain the code and it has a few limitations.
这里他们教我永远不要使用接口构建器，说维护代码很困难，而且它有一些限制。
This is only partially true. The principal reason I don't like Interface Builder and Xcode in general is that a lot of beginner programmers think that it is the only way for developing iOS/OS X apps. They have never heard of gcc and clang, they don't know what the compiler and linker error messages mean, they can't use make, and they have no idea about what the difference between the Objective-C language, the Cocoa (Touch) APIs, the IDE and the compiler is.
这只是部分正确。我不喜欢界面构建器和Xcode的主要原因是，很多初学者认为这是开发iOS/OS X应用程序的唯一途径。他们从未听说过gcc和clang，他们不知道编译器和链接器错误消息的含义，他们不能使用make，他们也不知道Objective-C语言、Cocoa(触摸)api、IDE和编译器之间有什么区别。
After all, they start using Interface Builder and Xcode with all of its quirky and sometimes strange/illogical features (and bugs as well), but when they're in the need of developing something non-obvious, they don't even realize there is a method for, for example, creating views and view controllers programmatically (yes, I've seen this very question on *).
毕竟,他们开始使用界面构建器和Xcode的古怪,有时奇怪/不合逻辑的特性(错误),但当他们在发展中一些不明显的需要,他们甚至不知道有一个方法,例如,创建视图和视图控制器编程(是的,*我见过这个问题)。
So, when abused (or rather, used too early), Interface Builder and all of the "convenient" features lead to programmers learning bad concepts and missing some important pieces of practice and experience.
因此，当滥用(或者更确切地说，使用得太早)时，接口构建器和所有“方便”的特性会导致程序员学习糟糕的概念，并遗漏一些重要的实践和经验。
However, if you're a senior developer, who has all the necessary skills, and you feel you could write an entire application from scratch, using just a simple text editor and a Makefile, then you are by all means permitted to use IB, and even encouraged to do so if you feel that's more comfortable than hammering out code.
然而,如果你是一个高级开发人员,所有必要的技能,你觉得你可以从头开始编写整个应用程序,仅使用一个简单的文本编辑器和一个Makefile,那么你就意味着允许使用IB,甚至鼓励这样做如果你觉得更舒适比敲定代码。
So, to sum up:
所以,总结:
Using interface builder is really a bad practice?
使用接口构建器真的是一个坏习惯吗?
No. Rather abusing it and not making the effort to learn the programmatic approach to UI stuff is bad practice.
不。与其滥用它，不如不去学习UI的编程方法，这是不好的做法。
Post scriptum: I have quite a lot of experience with iOS development, but I still find Interface Builder rather inconvenient and inconsistent. I generally use code for everything. But that seems to be my personal preference. One advantage is, however, that if one creates everything by code, then another programmer without access to these Apple-specific tools will be able to contribute to the project as well. This is a point where the "it's hard to maintain" part comes true...
编剧:我在iOS开发方面有很多经验，但我仍然觉得界面构建器非常不方便和不一致。我通常对一切都使用代码。但这似乎是我个人的偏好。然而，一个优点是，如果一个人通过代码创建所有东西，那么另一个没有访问这些特定于苹果的工具的程序员也可以为这个项目做出贡献。在这一点上，“很难维持”的部分实现了……
For example, until I didn't have enough money for a Mac, I used Linux for developing iOS apps (yes, that is actually possible). I couldn't use IB and Xcode, yet I have done loads of applications and tweaks (for jailbroken iOS, of course), and that was just fine.
例如，在我没有足够的钱买Mac之前，我用Linux开发iOS应用程序(是的，这是可能的)。我不能使用IB和Xcode，但我已经做了大量的应用程序和调整(当然是针对越狱的iOS)，这很好。
Post scriptum #2: another reason for avoiding the use of IB could be the need for dynamic UIs. If you heavily rely on animations, custom UI elements, etc., it's hard to do everything in Interface Builder. Last summer, I had to rewrite a login screen of an application, and honestly, I don't know how I could have realize our designer's ideas if I had had to use Interface Builder. The UI/UX was so dynamic and it had so many ways to change that it was absolutely necessary to have fine control over each and every pixel. And that's something that code is better at than IB.
Post scriptum #2:避免使用IB的另一个原因可能是需要动态ui。如果您严重依赖动画、自定义UI元素等，那么在Interface Builder中很难实现所有的操作。去年夏天，我不得不重写一个应用程序的登录界面，老实说，我不知道如果我必须使用接口构建器，我如何才能实现我们的设计人员的想法。UI/UX是如此的动态，它有如此多的方法来改变，所以对每个像素都进行精细的控制是绝对必要的。代码比IB做得更好。
#2
7
I strongly disagree with the idea that IB is a bad practice. Interface Builder has the following advantages over code:
我坚决不同意IB是一个坏习惯的观点。与代码相比，接口构建器具有以下优点:
-
when working with complex (and even simple) graphical interfaces, IB cuts the code down to a mere fraction - for example, simply creating a button in IB takes a few seconds, whereas in code, that translates to dozens of lines, especially if the button is to be styled
当使用复杂的(甚至简单的)图形界面时，IB将代码减少到很小的一部分——例如，在IB中创建一个按钮只需要几秒钟，而在代码中，这将转换为几十行，特别是如果要对按钮进行样式化的话
-
using autoresizing masks for supporting multiple resolutions and devices is a breeze - this is important as Apple is now pushing towards resolution-independent apps
使用自动调整面具来支持多种分辨率和设备是一件轻而易举的事——这一点很重要，因为苹果目前正在推动与分辨率无关的应用
-
changing/tweaking properties of views is a matter of a few clicks rather than lines of code, especially if working with images
更改/调整视图的属性只需要几次单击，而不是几行代码，特别是在处理图像时
However, there is one disadvantage (that comes to my mind):
然而，有一个缺点(我想到了):
- it can hard to pinpoint what might be causing a graphical problem, since it will be hidden away in in the IB file than in the code
- 很难确定是什么导致了图形问题，因为它将隐藏在IB文件中，而不是代码中
#3
4
Absolutely not. Interface Builder is a really powerful way of creating UI really quickly. Especially with Storyboards it allows you to make functional apps with very little code.
绝对不是。接口构建器是一种非常强大的快速创建UI的方法。特别是故事板，它允许你用很少的代码制作功能应用程序。
The issue of it "creating bad code" is rubbish as the IB doesn't create any code. The files it creates are essentially XML files that complement the code that you write.
it“创建坏代码”的问题是垃圾，因为IB不创建任何代码。它创建的文件本质上是XML文件，可以补充您编写的代码。
Most of the apps I've developed have been mostly started on IB.
我开发的大多数应用都是在IB上开发的。
Obviously, you can't do the FUNCTIONAL stuff of your app. I.e. you can't tell a button exactly what to do. But you can point it to a function that you have written and get a working button with almost no code.
显然，你不能做你的应用程序的功能，也就是说，你不能确切地告诉一个按钮该做什么。但是您可以将它指向您已经编写的函数，并获得一个几乎没有代码的工作按钮。
Most of the UI in iPhoto on iPad and iPhone is written in Interface Builder.
iPad和iPhone上iPhoto中的大部分UI都是用Interface Builder编写的。
#4
3
Much has been said, but I am still going to give my 2 cents for this discussion...
已经说了很多，但是我还是要为这次讨论贡献我的2分。
Until some point I agree with H2CO3, it's better to understand what's going under the hood, than keep using shortcuts to achieve something. That works most of the time, the thing, and that's where I strongly disagree with H2CO3, is the following:
在某种程度上，我同意H2CO3的观点之前，最好先了解它背后的情况，而不是一直使用快捷键来实现某些目标。这在大多数情况下都有效，我强烈反对H2CO3，是这样的:
-
Most of the people that use a technology (C#, Java, HTML, iOS, etc), they use it because their Company needs them to use it, because someone else is actually going to pay you to work with that. And not because you actually woke up in the middle of the night and suddenly had the urge to learn C.
大多数使用技术(c#、Java、HTML、iOS等)的人使用它，是因为他们的公司需要他们使用它，因为其他人会付钱给你来使用它。不是因为你半夜醒来突然有学习C的冲动。
-
If someone asks you tomorrow to create an iOS App and you never developed for iOS before, I truly doubt you are going to create an App from scratch without using XIB's or Storyboards (Which I hate btw).
如果明天有人让你创建一个iOS应用程序，而你以前从未为iOS开发过，我真的怀疑你是否会在不使用XIB或Storyboards(我讨厌它)的情况下从零开始创建一个应用程序。
What H2CO3 proposes is a utopia... Where you really understand what is going on beneath, but because you are such a "leet", you are able to use shortcuts, like XIBs. Well, things don't work that way, and sooner or later you will have to do some shitty thing to deliver something on the next morning.
H2CO3提出的是一个乌托邦……当你真正理解下面发生了什么，但是因为你是一个“leet”，你可以使用快捷方式，如XIBs。好吧，事情不是那样的，你迟早要做一些该死的事情才能在第二天早上交付一些东西。
I prefer, and that's personal perspective, to use a XIB, than to use the first 3rd party library that comes in front of me. And I think that's more reasonable than doing an interface by hand. I prefer to understand the code, and do it by myself, than using for instance a library to help me download/upload stuff.
我更喜欢使用XIB，这是我个人的观点，而不是使用前面的第一个第三方库。我认为这比手工操作界面更合理。我更喜欢自己理解代码，而不是使用一个库来帮助我下载/上传东西。
For wrapping this up, my advise to the person that asked this is:
最后，我的建议是:
Try to understand why things are done the way they are. Above all, try to be a better programmer in each new project that you face. If something new comes up (new iOS version) spend a day or two to see what's new, and what could you use. XIB's are perfectly fine to be used, but spend some time creating UIView's by hand, so you can see all the flexibility they give you. And above all, run away from Storyboards (^^)
试着去理解为什么事情是这样做的。最重要的是，在你所面对的每一个新项目中努力成为一个更好的程序员。如果有新东西出现(新的iOS版本)，花一两天时间看看有什么新东西，你可以用什么。使用XIB是完全可以的，但是要花一些时间手工创建UIView，这样您就可以看到它们给您的所有灵活性。最重要的是,逃离故事板(^ ^)
P.S: A senior developer it's not just a guy that has a "better Kung fu than you".. It's more than that.
P。S:高级开发人员不只是一个“功夫比你强”的人。它是更多。