

NSLogger – a flexible logging tool for OS X and iOS - robert-boehnke
https://github.com/fpillet/NSLogger

======
macrael
You might want to consider renaming this project. The NS prefix is reserved by
apple for framework classes. The entire purpose of prefixing classes in Cocoa
is to prevent namespace collisions between different organizations, which
using NS outside of apple breaks. It doesn't actually look like you are using
the NS prefix in any of your code, so you're not technically violating the
below rule, but I still think it worth considering. NS kindof means "from
apple".

"Objective-C classes must be named uniquely not only within the code that
you’re writing in a project, but also across any frameworks or bundles you
might be including. As an example, you should avoid using generic class names
like ViewController or TextParser because it’s possible a framework you
include in your app may fail to follow conventions and create classes with the
same names.

In order to keep class names unique, the convention is to use prefixes on all
classes. You’ll have noticed that Cocoa and Cocoa Touch class names typically
start either with NS or UI. Two-letter prefixes like these are reserved by
Apple for use in framework classes...

Your own classes should use three letter prefixes. These might relate to a
combination of your company name and your app name, or even a specific
component within your app. As an example, if your company were called
Whispering Oak, and you were developing a game called Zebra Surprise, you
might choose WZS or WOZ as your class prefix."

[http://developer.apple.com/library/ios/#documentation/cocoa/...](http://developer.apple.com/library/ios/#documentation/cocoa/conceptual/ProgrammingWithObjectiveC/Conventions/Conventions.html)

In practice many people use two letter prefixes for their classes, you should
use a prefix with your classes!

The project looks great, I've been wishing for a more comprehensive logging
system with filtering built in for a while now. Thanks!

~~~
GuiA
Side question: Did NS initially stand for NextStep, or am I completely off?

~~~
weaksauce
That's exactly what it is named.

~~~
i386
From what I have read, the prefix used to be NX* in the NeXTSTEP days and was
changed to NS* around the time OpenStep came on the scene.

~~~
millerm
Actually, I believe the actual prefix of NS originally meant Next/Sun whe Next
was working with Sun Microsystems. But, who knows? We need one of the original
developers to help clear this up.

------
pkaler
The log viewer and query tools looks excellent.

Here are some (hopefully) constructive comments:

\- As others have mentioned, change the NS prefix. Only Apple should be using
that.

\- The API is not canonical looking Objective-C/Cocoa. It looks like the
programmer has a Windows/C++ background

\- I only took a quick look but I didn't see logging macros that conditionally
compile out logging for release builds

\- Internally the logger uses pthreads. This is going to make it difficult on
a client that uses Grand Central Dispatch to reason about code when they are
debugging something. Consider using queues and operations rather than firing
up worker threads. Take a look at CocoaLumberjack for their approach

\- Create a Cocoapod to spur adoption

~~~
i386
Is there a good guide to writing canonical looking Objective-C /Cocoa APIs?

I read the .NET Framework Design Guidelines back when I was doing .NET and it
was an excellent how to guide on writing APIs that behaved and felt like they
were part of the BCL. Something like that for Objective-C and Cocoa would be a
boon.

------
eddieroger
Damn, I have dreamt of something like this for a while, but never sat down to
build it. I can't wait to try this out in my next project. A remote client is
brilliant, and would have really saved my bacon about a year ago when testing
an application in the real world.

I would agree, though, to avoid the "NS*" prefix, but that's been spelled out
in a different thread.

------
Aqua_Geek
Honest question: why does everybody seem to want to compile out logging on
release builds? Yes, if you're "printf debugging" that probably shouldn't be
in a release build. But I've found the ability to look at (optional, user-
enabled) logs invaluable in tracking down some obscure bugs in production.

~~~
stevoski
Performance concerns - whether warranted or not.

------
melito
Have used this in combination with CocoaLumberjack on a good number of
projects and it has come in VERY handy. Highly recommended.

Not too difficult to get it wired up with papertrailapp.com either - That
combo makes it VERY handy

------
MaxGabriel
From someone who hasn't used either, how does this compare to CocoaLumberjack?

~~~
uxp
I tried using NSLogger a couple months back, but ended up continuing to use
CocoaLumberjack, probably because it's just more familiar to me. NSLogger
requires one to write the macros that compile out debug logging, where as
that's a feature of CocoaLumberjack, but the Desktop viewer I found immensely
useful especially for the fact that it archives past logging sessions.

You can actually use CocoaLumberjack with NSLogger's Desktop Viewer though, by
adding NSLogger as an adaptor[0], but you're pretty much stuck at the same
issue of setting up less-than-trivial conditionals for compiling out the
library and adaptor when building release versions. Not a huge issue in
itself, but it doesn't lend itself for writing trivial applications.

[0]: [https://github.com/steipete/NSLogger-CocoaLumberjack-
connect...](https://github.com/steipete/NSLogger-CocoaLumberjack-connector)

