As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm still learning, so I don't have my working convention yet for grouping my properties in header files, and the same is about synthesize calls. Sometimes I group them in one order, sometimes in another order. Also, I'm synthesizing those properties in one or two paragraph of calls, but I saw some people use different synthesize call for every property. However, my laziness tell me that approach is a little big coding overhead :)
Later, I'm adding new stuff as development goes thought, so very often, I end up in a sort of a mess IMHO :) I do understand and try to use as much MVCs as I can, but still some of my MVCs contain 20 - 30 properties because of a lot of graphics that are designed in IB. Later, I'm doing some refactoring but still curious maybe some of you have a strong rules for code cleanness?
With #synthesize I always put them on separate lines so each prop has its own synth directive, this really helps with version control and clarity.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I'm curious of what the pros and cons are of these two, DOM and XPath. What does XPath provide that DOM does not, and the other way around? I'm not looking for performance or anything like that, just what is the main difference between the two when it comes to navigation? When is DOM better to use than XPath for example?
Thanks.
They are complementary rather than competing. DOM provides a tree model of XML with low-level navigation capability (get first child, get next sibling, etc); XPath adds a much higher-level search and navigation capability (e.g. get the average price of all books, get the title of the last chapter).
Note also that DOM is just one tree model for XML, and is very far from being the best: it's the first and the worst, and it's a shame that so many people still use it. In the Java world there are much better designs available such as JDOM and XOM.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
As per the article at W3Techs, Perl ranks the lowest among the server side scripting languages, even less than Java? Is there any reason behind it? Perl, as far as I see, is very popular, and an awesome language, how come it is hardly used by websites? Does it have issues with server side scripting?
This article has a lot of details on how W3Techs gets their data: http://w3techs.com/blog/entry/usage_of_perl_for_websites_fell_below_1_percent
As i did some analysis on this, let me summarize in short that the data presented by W3Techs is deeply flawed and extremely misleading. First off, it is important to know that they detect technologies of sites by running simple scripts at them that look for file suffixes in urls and then just take that and never verify with the site owner. As such they have a "no-detect" rate of 17.6% (plus an unknown "false-detect" rate). A more correct version of their chart would be this:
If you'd like to get more details and more mistakes in their data methodology, please take a look at the comments of the article, especially those written by "Mithaldu" or "Christian Walde", i.e. me. I posted extensively there as to why their data is nearly useless and why they're even misinterpreting the data they do have.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
If I want to use a traditional approval type workflow in a regular asp.net system, for example
an order that needs an approval before order is placed. Rather than having the traditional
enum for OrderStatus, can I benefit from using microsoft WF4 (Workflow version 4) for this
or will I just generate more complexity and more code for no added benefit?
Any time you have a long running operation like this WF4 is a good possibility. The fact that the graphical designer allows you to show the actual running process, not a Visio copy of it, is also a huge benefit.
There is however a learning curve to WF4 and there are times you have to do things the WF4 way instead of the C#/VB way you did before. That said there is certainly a benefit, thinks like an approval request not being handled in, lets say, 14 days is very easy to do in WF4.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
A small debate flared up in a question about protected member variables regarding the use of getters/setters. There are lots of questions already over whether getters/setters are evil, however one particular argument against them, which was posed by two separate individuals with much higher reputation than myself, struck me.
One said that getters/setters made the code only 0.01% less brittle, and the other stated that adding 10 lines of code where one would do makes the code more brittle.
This goes against most of what I had previously read, been taught, thought, or experienced. Does anyone else agree/disagree with those comments?
I know it is close to herecy, but I hate get/set methods. Loathe them. Almost never write them.
Generally, a class should either provide much more high-level operations than directly and simply reading and modifying internal state variables, or it should get the hell out of the way and act like the struct it is.
Even if I were to write one, I would almost never use it inside the class. The whole point of them is that you can change the internal representation of thing without affecting a client. Inside the class, it is the internal representation you care about! If you are tempted to do a lot of operations on the class using its own interface inside the class, you probably have a second class in there fighting to get out.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
What are the important things(concepts) I have to learn to develop iPhone applications.
Memory management rules.
Understand the Design Patterns that Cocoa use. Pay particular attention to the Model View Controller pattern and make sure you know how to use it well (Fat models, thin Controllers). This will make your life a lot easier down the line!
Memory management rules has been covered already.
Learning your way around the Apple documentation. The more familiar you become with this site, the easier it will be to find the information you need. I have found a lot my time developing for iPhone is spent just navigating around the documentation looking things up.
Learn C, and understand how Objective C is different. A large part of this is understanding how Objective C's messaging is different to calling functions in C.
Learn Key Value Coding.
Objective C is a dynamic language, which when you understand this means a lot of the wierdness of Objective C makes sense.