I am currently doing safe Rust bindings for a C library, that has a lot of constants defined in #define which have an UPPER_SNAKE_CASE name.
For most cases it is not a problem (Rust uses the same convention) but actually, in this C library, some functions use them to give a type to a void* pointer, so I was thinking about wrapping them in a structure containing the correct data and use them as an interface for the user.
However what is the preferred way of naming those structures? Should I use a CamelCase name to match with Rust conventions or keep close to the C library names and use an upper snake case?
I think it's entirely a matter of taste. Personally I split C library wrappers into two levels:
FFI, as a separate module or even separate crate, which is as close to C library as possible, including its naming conventions and data types. In that case I'd keep -> *mut libc::void (example).
Safe, high-level wrapper, using Rust's data types and naming conventions (example).
Related
I want to provide some functionality for compiling sources of a specific kind (e.g. java).
As the process of compilation needs additional information i need to give in some more arguments and not only the sourcefile. E.g. working directory, compiler parameters and so on.
There are two ways in my mind how to design it:
Using OOP, that means creating a compiler class, saving the
additional arguments when constructing a specific compiler object
that can then be used for compiling by just providing the sourcefile
Not creating a class for creating objects but just a (static final?)
closure in a class and then using curry to pass in the needed
arguments and returning another compile function which can then be
provided by for example just the sourcefile to compile it
What are the pros and cons? Is there maybe an even better way to get things done?
According to me it only depends on if this should be done well or it's just a kind of a proof of concept. If there will be multiple source files with different types, then it's better to create well-designed, robust class hierarchy. Otherwise You can use a bunch a predefined closures if suites your needs.
Mind the fact that these two solutions are not mutually exclusive. You can still create a robust class hierarchy that will be using predefined closures internally.
Is there any way to create "private objects" when creating a framework? (meaning, classes that won't be exported outside)
I have a problem that my frameworks uses the JSON library and when projects using my framework try to also include the JSON library they get a "symbol already defined" error.
Thanks!
Yoav.
With Objective-C that's not really possible. There are some guidelines to prevent collision though, for example one should use prefixes for members that are to be 'hidden' for other people and member variables are often prefixed with a underscore as well (Apple reserves the right to use 2 underscores). Which JSON framework are you using? Perhaps consider SBJSON if you aren't using it already, it uses the prefix (SB) to prevent collision.
From Apple's documentation:
Prefixes are an important part of names in programmatic interfaces. They differentiate functional areas of software. Usually this software comes packaged in a framework or (as is the case of Foundation and Application Kit) in closely related frameworks. Prefixes protect against collisions between symbols defined by third-party developers and those defined by Apple (as well as between symbols in Apple’s own frameworks).
A prefix has a prescribed format. It consists of two or three uppercase letters and does not use underscores or “sub prefixes.” Here are some examples
NS: Foundation
NS: Application Kit
AB: Address Book
IB: Interface Builder
Use prefixes when naming classes, protocols, functions, constants, and typedef structures. Do not use prefixes when naming methods; methods exist in a name space created by the class that defines them. Also, don’t use prefixes for naming the fields of a structure
If you want to stick with the JSON library you use, and the "namespace" is the cause of the issue, consider adding a prefix to your own classes.
In c# I use namespaces in java I use packages. Is there a way to keep classnames short in objective c?
Objective-C only has one, single global namespace. That is why you often see classes called SBJsonParser, so that the class name doesn't collide with other JsonParsers out there.
The general recommendation I have seen is to prefix your classes with either your initials or with a few initials for the project you are working on, the class name, then (sometimes) what "type" of class they are (as is the apparent convention for view controllers).
Honestly, I am right there with you Mel, I would be absolutely exhilarated for Objective-C to add some sort of namespacing feature, at least something to sort out classes a bit more (and a bit easier).
I am wondering what is actually the preferred way of naming variables: some_variable or somevariable.
Looking at some libraries, I have seen both. What is more, some wide-spread style conventions like Google C++ Style Guide allow both.
What do you prefer and why? Is there a rule or good practice which tells when to use which? And does the same applies to argument names in functions/methods?
And is mixing those two conventions a good idea? If yes, when should the first naming conventions be used, and when the second one?
Use what's most readable and least confusing.
You should follow whatever naming convention makes sense to you.
For me, I always use camelCase for variables and PascalCase for public methods and properties.
The C++ standard libraries use both conventions for function and class names, though the _ convention is apparently gaining popularity (it's used in most recent additions, since the STL got standardized). Stick with your project guidelines, or make up your own, but apply them consistently.
My personal style is to use some_function for functions, somevar for variables, PascalCase for class names. I don't have a copy of The C++ Programming Language by Stroustrup around, but I believe this is his style as well.
According to Apple, two to three letter prefixes should be used
when naming classes, protocols, functions, constants, and typedef structures.
Does this include classes which are not intended to be part of a framework, simply used internally in an application? I realize this is relying on other developers that develop frameworks you might be using to use prefixes, but that seems acceptable. What about Core Data entities? If I generate classes from them, shouldn't they be prefixed as well?
To be safe, use a prefix for all classes in your application. All classes are loaded into a single flat namespace in Objective-C and the prefix prevents collisions both now and in the future.
This also includes CoreData entities; they should also use the same prefix as the rest of your application's classes.
Also note that you may decide some of this code could be used elsewhere, so using prefixes now will safeguard you from potential collisions in the future.