code-organization

I'm building my first android app, and it's gotten a little messy already. I'm using List/detail patterns because they're what fit the circumstances, but because I'm developing for both mobile and tablet it's getting a bit out of hand. For every screen (List/detail being one screen), four files are created. ListActivity, ListFragment, DetailActivity, DetailFragment. Having four screens so far, and literally just starting the project, I have 12 files, plus three helper files for one database table. What I'm asking, is what's the best way to organize this? I'm using Android Studio, and it seems

I'm getting started with Python (it's high time I give it a shot), and I'm looking for some best practices. My first project is a queue which runs command-line experiments in multiple threads. I'm starting to get a very long main.py file, and I'd like to break it up. In general, I'm looking for: How do python programmers organize multiple source files? Is there a particular structure that works for you? My specific questions include: Should each class be in a separate file? How should I organize unit tests relative to source code? Where should I put doc comments, specifically those for command

I'm just learning some Swift and I've come across the section that talks about nesting functions: Functions can be nested. Nested functions have access to variables that were declared in the outer function. You can use nested functions to organize the code in a function that is long or complex. From here So if the purported benefit is to "organize the code", why not just have the nested function independently, outside of the outer function? That, to me, seems more organized. The only benefit I can discern is that you "have access to variables that were declared in the outer function", but this

In C# you can put files in folders corresponding to their namespaces and view them in the Solution explorer. In F# it seems I have to put everything in plain specifically ordered list for compilation. When I get to scale of ~300 of classes it gets a bit confusing and disorganized and I start to envy C# and think that probably it is the price for type inference. Are there better options than splitting to several assemblies? Judging by F# compiler source its the route they have taken but I have pretty large system of interconnected components (Controller - ViewModel - View, > 300 classes) I want

I’m very much new in software development. Personally I think layered architecture is a great way to reduce the complexities that arise in the process of software development in object oriented approach and, not to mention, to keep your code organized. Now, I’ve run into some problems to be introduced with DDD (Domain Driven Design). Ofcourse, beginner level ones. Here it is – Let's say, I want to build an application to save “person” related data in database and display person details in a wpf datagrid (DDD is definitely not for the apps of such scale, but just to keep things simple for an

We have Java and Flex projects. We currently have 1 base pom that contains the configurations we want to use for both projects. Problem with this is: Flex projects inherit configuration, for example, for javadoc and pmd plugins, which is not desirable. I want to clean it up and have a real base pom, and then a java-base-pom and a flex-base-pom . But how does this work in a multi-module that has both a Flex part and a Java part? We have plugins to our own application where we use the following structure: my-plugin my-plugin-client (flex) my-plugin-server (java) my-plugin just contains a pom.xml

I've come across some code that has a large static function in a header file and i'm just curious when it is/is not ok to do this. For example, if many .c files include the header, why not just define the function non-static and link it in ? Any advice or rules of thumb on when/when not to put static function definitions in header files in C would be appreciated, thanks Some ideas: One possible legitimate use I can think of is when you want to make a function available without creating a symbol with external linkage and polluting the external namespace. (But then you could just use an obscure