Programming

28458 readers

271 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 3 years ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

UlrikHD@programming.dev

bugsmith@programming.dev

Spyro@programming.dev

What is your preferred import style (sh.itjust.works)

submitted 1 day ago by programmerlexi@sh.itjust.works to c/programming@programming.dev

39 comments fedilink hide all child comments

There are a few I'm aware of:

Rust-style use (multiple imports per statement, renaming items using as)
Java-style import (single import per statement, no renaming (afaik))
Zig-style let xlib = @import("xlib") (imports as assignments)
C-style #include (no importing, just pastes the code of the named file)

you are viewing a single comment's thread
view the rest of the comments

[–] eleijeep@piefed.social 10 points 1 day ago (1 children)

There is a hidden detail that's worth mentioning about C and C++ style includes: Because compilation and linking are two separate steps, the definitions (included from header files) and the compiled object code that implements those definitions can be kept strictly separate such that you could have two different implementations of the same definitions that are switched in at linker time, for example as a way to provide mock implementations of a specific compilation unit for a unit test, by modifying which object file is passed to the linker.

In some languages this is harder to do as it would require some fiddling with the classpath (in Java for example) or designing with dependency injection in mind from the beginning (inversion of control).

I'm not saying it's a killer feature, but it's something worth noting nonetheless.

[–] TootSweet@lemmy.world 2 points 23 hours ago

The Java logging library "SLF4J" works basically this way. It's a "broker" sort of library. You use the SLF4J API to log and there are different backend implementations that can tie your logging statements to an actual logging backend. So you can do things like switching backends without changing code or using one backend (say, to STDOUT) in local and a different one (Syslog, maybe) in prod.