15

This is just a simple code-style question. Imagine you're writing a function in language 1 that is supposed to be called from language 2. Should the function follow language 1's style guidelines or language 2's style guidelines?

For example:

// This file is written in language 1
// Language 1 uses `PascalCase` and language 2 uses `snake_case`

// Follow language 1's style guidelines:
function FunctionToBeCalledFromLanguage2() {}

// Or language 2's:
function function_to_be_called_from_language_2() {}
// This file is written in language 2
// Language 1 uses `PascalCase` and language 2 uses `snake_case`

// Call the function from language 1
language1.FunctionToBeCalledFromLanguage2();
// Or:
language1.function_to_be_called_from_language_2();
1

6 Answers 6

54

In general: when you write some library in language 1, you use the conventions from language 1, and use an alias mechanism to provide an API to map the function names to the case conventions of language 2.

The only case where you might skip this additional API mapping is when you know for sure that your library written in language 1 has the one-and-only purpose to provide functions for "language 2" and no other language environment at all. Then it might be simpler to use conventions from "language 2" directly for the library API (but you should check if that is really the case).

3
  • 3
    Why should language 2 even know what language 1 is? It's very likely that the foreign function interface is C ABI and idioms of both languages are lost in that translation.
    – ojs
    May 2, 2023 at 7:04
  • @ojs: IMHO it is not very sensible to to make assumptions about "likeliness" for a question which just talks about "language 1" and "language 2", with no other indication which real world environments the OP had in mind. It is also pretty clear the OP wrote "languages", butl, the question is actually not about "languages", only about case conventions for function names (though it is correct that some language environments like the Java ecosystem, or the C# ecosystem, or Python/Pep8 show a certain popularity for certain case conventions).
    – Doc Brown
    May 2, 2023 at 17:54
  • 1
    ... note also different environments and frameworks provide different tools for their FFI, even when it comes to C ABIs, there sometimes exist generative tools to unburden developers from making their own mapping or aliasing.
    – Doc Brown
    May 2, 2023 at 18:00
12

I believe you should follow the conventions of the language you're writing in, with few exceptions, for these reasons:

  1. You say that the function is "supposed to be called from language 2", but it seems unlikely that can you guarantee it will always be called from Language 2 in the future.
  2. The people best suited to maintaining the function will be the people who are comfortable working in the language it's written in, and they will be best served by following the conventions they are familiar with.
  3. An IDE and perhaps even a compiler will output warnings for violating those conventions.
  4. Except in exceedingly rare circumstances, calling functions in language 1 from language 2 is not a new problem that you are solving on your own; this is something other people have dealt with. People working on interop software should be familiar with seeing such function name styles. They may even find it more confusing if the name violates Language 1's conventions.

I think that you'll also find this isn't a significant issue in most candidates for Language 2. In Java and C#, you can't simply call a function by name like that, anyway; you'd pass a string to a loader function, e.g., NativeMethods.GetProcAddress(pDll, "FunctionToBeCalledFromLanguage2");, making this entirely a non-issue. Groovy supports invoking Java functions directly by name, but it has the same naming conventions, obviating the question.

9

There is no definitive answer. Coding style is subjective.

However, I think it would be a sane general rule, that when you choose a coding style, you choose it for the readers of your code. Who would be your primary audience?

  • If you are writing for an audience that mainly uses language 2, your function names should follow language 2's coding conventions.
  • If however, you are writing for an audience that mainly uses language 1, and the function you write, will typically be abstracted away from language 2 users by a wrapper library, you should choose language 1's coding conventions.
5
  • 1
    coding style is not a subjective thing. normal companies define their own coding style May 2, 2023 at 5:31
  • 13
    @BЈовић - And the folks defining these coding styles at those normal companies are not subjective at all, right? :-) Subjective doesn't need to mean that each member of a team does something else. It's just the opposite of objectively measurable in this context.
    – Martin Ba
    May 2, 2023 at 8:05
  • @MartinBa it is possible to check the coding style in CI, meaning it is not possible to merge (or even check in) the code if not adhering to the style. In such case, question above is meaningless. May 2, 2023 at 9:03
  • 9
    Having every contributor follow the same style guide leads to cleaner code, just like having everyone driving their car on the same side of the road leads to smoother traffic. But even if your country have put into law which side of the road cars should drive on, doesnt make it an objective truth that cars necessarily needs to drive on the right (or left) side of the road. Nor does checking coding style in CI make the style guide any more objective.
    – Jo Totland
    May 2, 2023 at 9:18
  • 2
    Specifically: The decisions made by the authors of the style guide are subjective, but the question of whether a given piece of code conforms to the rules listed in the style guide is objective. May 3, 2023 at 1:52
5

I would write a wrapper API in the client language 2 to call functions implemented in language 1. Good thing to do anyway as may simplify various cases of refactoring later.

Then, just inside the wrapper, I would call functions of the language 1 named by the rules of the language 1.

The wrapper may also convert the passed or returned data structures between representations that are more traditional for another language. For instance, with Python ctypes, Python list cannot easily go right into C++ layer but some conversion may be possible.

-1

I would use function_to_be_called_from_language_2(); forget about style guidelines..

function_to_be_called_from_language_2(); is much more readable at first glance than FunctionToBeCalledFromLanguage2

Aside from performance we should always prioritize readability of the code

"but it doesn't follow the style guidelines!".. who cares?

This statement "write an alias mechanism to provide an API to map the function names to the case conventions of language 2."

Could be translated as:

"Waste your and the companies time by writing the alias mechanism with the end goal being making the code less readable"

Doesn't sound very logical to me?

If the style guidelines had you define a method name like this

function GeTcArViNnUmBeR()

Would you follow them? I should hope not.. because those type of style guidelines would encourage you to make the code less readable..

Is that not the case here?

-1

First investigate if the compiler / linker / tools are able to change the names to adapt to the language used.

As an example, the names of methods in Objective-C often have semantics. Like a method beginning with “init” have special meaning. When using these methods from Swift, the name is automatically mapped to a different name with the same meaning.

And once in a while you have a case where this doesn’t work. Where something matches this semantics pattern by coincidence. For these case you can tell the Objective-C compiler what the Swift name would be and vice versa, and actual code looks fine in either language.

For other situations: Consider writing code that is fine for the implementation language and add a wrapper that is only ever used by the calling language.

Not the answer you're looking for? Browse other questions tagged or ask your own question.