Apple Carbon/CoreFoundation style guide? - macos

Cocoa is well-documented and there is a lot of information on writing Cocoa code in good form. I'm working on some code that works closely with hardware, requiring me to use CoreFoundation and Carbon APIs often. Is there any sort of 'style' guide for understanding libraries such as Carbon and CoreFoundation from Apple? Apple's example code is littered with things like:
kSomeValue
CFMightDoSomethingUseful
I can deduce that CF means CoreFoundation and k might be for constants or enumerated types, but I would like to verify this and learn more about the other syntactic styles.

Core Foundation Design Concepts at the Mac Dev Center actually cleared up my question.

I can deduce that CF means CoreFoundation …
Specifically, it's the prefix for functions, types, and constants in the Core Foundation framework.
… and k might be for constants or enumerated types…
Yup. This one dates back all the way to the Toolbox days, before Core Foundation even existed. I believe it was a Pascal custom.
Aside from these rules, I'm not aware of any general CF/Carbon style guides.
You might try going even more general and picking up some books on C style. Compare and contrast between them; there is often no objectively-right answer.
One that I like is “Enough Rope to Shoot Yourself in the Foot”, by Allen Holub. It's witty and makes some good cases. Holub has a summary version on his website (just the rules themselves, without the detailed explanations); as far as I can tell, the full book is out of print.

Related

Is there an easy way to replace a deprecated method call in Xcode?

So iOS 6 deprecates presentModalViewController:animated: and dismissModalViewControllerAnimated:, and it replaces them with presentViewController:animated:completion: and dismissViewControllerAnimated:completion:, respectively. I suppose I could use find-replace to update my app, although it would be awkward with the present* methods, since the controller to be presented is different every time. I know I could handle that situation with a regex, but I don't feel comfortable enough with regex to try using it with my 1000+-files-big app.
So I'm wondering: Does Xcode have some magic "update deprecated methods" command or something? I mean, I've described my particular situation above, but in general, deprecations come around with every OS release. Is there a better way to update an app than simply to use find-replace?
You might be interested in Program Transformation Systems.
These are tools that can automatically modify source code, using pattern-directed source-to-source transformations ("if you see this source-level pattern, replace it by that source-level pattern") that operate on code structures rather than text. Done properly, these transformations can be reliable and semantically correct, and they're a lot easier to write than low-level procedural code that navigates and smashes nanoscopic actual tree structures.
It is not the case that using such tools is easy; such tools have to know how to parse the language of interest into compiler data structures, (e.g., ObjectiveC), process the patterns, and regenerate compilable source code from the modified structures. Even with the basic transformation engine, somebody needs to carefully define parsers (and unparsers!) for the dialects of the languages of interest. And it takes time to learn how to use such a even if you have such parsers/unparsers. This is worth it if the changes you need to make are "regular" (in the program transformation sense, not the regexp sense) and widespread (as yours seem to be).
Our DMS Software Reengineering toolkit has an ObjectiveC front end, and can carry out such transformations.
no there is no magic like that

On the use of of Internal`Bag, and any official documentation?

(Mathematica version: 8.0.4)
lst = Names["Internal`*"];
Length[lst]
Pick[lst, StringMatchQ[lst, "*Bag*"]]
gives
293
{"Internal`Bag", "Internal`BagLength", "Internal`BagPart", "Internal`StuffBag"}
The Mathematica guidebook for programming By Michael Trott, page 494 says on the Internal context
"But similar to Experimental` context, no guarantee exists that the behavior and syntax of the functions will still be available in later versions of Mathematica"
Also, here is a mention of Bag functions:
Implementing a Quadtree in Mathematica
But since I've seen number of Mathematica experts here suggest Internal`Bag functions and use them themselves, I am assuming it would be sort of safe to use them in actual code? and if so, I have the following question:
Where can I find a more official description of these functions (the API, etc..) like one finds in documenation center? There is nothing now about them now
??Internal`Bag
Internal`Bag
Attributes[Internal`Bag]={Protected}
If I am to start using them, I find it hard to learn about new functions by just looking at some examples and trial and error to see what they do. I wonder if someone here might have a more complete and self contained document on the use of these, describe the API and such more than what is out there already or a link to such place.
The Internal context is exactly what its name says: Meant for internal use by Wolfram developers.
This means, among other things, the following things hold about anything you might find in there:
You most likely won't be able to find any official documentation on it, as it's not meant to be used by the public.
It's not necessarily as robust about invalid arguments. (Crashing the kernel can easily happen on some of them.)
The API may change without notice.
The function may disappear completely without notice.
Now, in practice some of them may be reasonably stable, but I would strongly advise you to steer away from them. Using undocumented APIs can easily leave you in for a lot of pain and a nasty surprise in the future.

Migrating from one C language to another, change Style?

I find myself in conflict, regarding which code style I should follow when using a different C language.
Currently I am doing work (different projects) in C++, C# and Objective-C
I noticed there is a lot of discrepancy in the conventions basic frameworks follow. Generally, I don't think it's a bad idea to adhere to these conventions, as it makes code feel more "integrated" into the environment. However it is hard for me to remember all the differences and apply principles correctly.
In C# for example, all methods of a class start Uppercase, while Objective-C seems to prefer camelCase style methods.
What tactic would you choose:
One style to rule them all (as far as applicable)
Stick with what is common in the given environment
I do especially like the google styleguides, which seem to recommend the latter. However I disagree with them on using spaces instead of tabs and their indentation in general (e.g. methods on same level as class etc.)
I think you should stick to the "accepted" styles for each language. My rationale for that is that I think it would be much easier to recall what environment you're in when you have to think in the style used for that language. It will also be much easier for someone who is familiar with that environment to look at your code and feel more comfortable with the style and formatting (i.e. less chance for them to misunderstand what they're looking at).
My rule with porting code is: Don't touch it unless you have to.
My rule with modifying old code is: Use the style of the file.
Outside of those two situations, things like coding standards and perhaps your own opinion on good style can come into play.

Bison (and flex) coding conventions

What are coding conventions and guidelines you suggest for writing Bison (.y) and flex (.lex) files?
Please address the length of the code sections and their style.
Thanks,
Asaf
P.S.,
There's an old thread about it here, but I'm looking for a more detailed answer (and to have it on SO!).
For questions like this in general I would typically see what other people have done. Good resources for this are Google Code Search and Koders. Both support searching by a specific programming language; however it appears that only Google has lex as a listed language.
Other than that, I generally try to keep to either 79 or 96 columns in source code, to make sure I can view at least 2 windows-worth of code side by side.

Code Length in IDE ( w/o modeling support ) versus Code Efficiecy in Compilation in Delphi

So - highly hypothetical question and more like discussion about your coding style and practice you use daily.
I will take as example: CodeGear RAD Studio 2009 (sorry to all D7 fans, but Unicode rules).
I have capability to expand/collapse functions/procedures/records and few other complex data structures, but what if code is lengthy?
What makes the task and its accomplishment efficient - the time required to add comments (its req actually) and expand/collapse necessary area or use OMT offered possibilities?
To give example input from myself - I have small app, about 1,5k lines and I do not use Modeling. Is it smart enough or do I lose a lot of time if I need to find some simple references or (event) calls?
If I understand your question correctly, it is a bout finding your way into code (yours or someone elses').
I use Model Maker Code Explorer for browsing through source code (and for refactoring existing code, and creating new code). At EUR 99, it is dead cheap for what it does.
It usually gives me a perfect overview of what I need, and has a nice 'search' interface as well.
If I need more complex searches, I usually use the GExperts (grep) search function: it is blazingly fast, and with good naming of your identifiers, it is usually a breeze to find stuff.
If I understand your question correctly, you want to know what is more efficient:
Use comments and expandable sections.
Use moddeling techniques.
I think it depends on personal style. Modeling can be great, but has dangers of spending too much time creating nice pictures.
We have a large app 500k+ lines. We do not use collapsable sections because we keep our file size acceptable and we have a good file organisation structure. We sometimes use modeling if complex parts are added (class diagrams and state diagrams). And we use lots of comment to explain difficult parts.
If you have Delphi 2009 you can use also the Delphi Class Explorer (in the View menu) in order to see your classes. It seems a little bit cryptic but only for the first 5 minutes. After this you will get used with it.
Also you can use CnPack a very impressive package in order to help you manage your project. Basically, in the IDE appears a new menu called 'CnPack' which has a bunch of wizards to help you find the way out in the source. Some examples:
Uses Cleaner
Procedure List (it gives you the incremental search capability for your procedures - very neat)
Bookmark Browser
etc.

Resources