pierrelgol / plib

PLIB

Overview:

PLIB is a C project designed to create a user-friendly library of functions. Its primary goal is ease of use, comprehension, and readability rather than prioritizing performance. The aim is to offer essential building blocks akin to those found in high-level languages like Python, without the typical complexities associated with C libraries.

Developed by students of 42, PLIB adheres strictly to the school's NORME, serving as the foundation for 42's projects.

Usage:

To get started:

1. Clone the repository:

   git clone https://github.com/pierrelgol/plib.git

2. Navigate to the directory:

   cd plib

3. Build the library:

   make release

Once built, copy plib.h and libplib.a to your project directory, and compile using:

gcc my_project.c -libplib.a

Contribution Guidelines

Getting Started:

• Ensure you have a GitHub account.
• Fork the repository on GitHub.
• Clone your forked repository locally: git clone https://github.com/your-username/plib.git
• Create a new branch for your work: git checkout -b feature-name

How to Contribute:

1. Bug Fixes or Feature Requests:

   • Check the issue tracker for existing issues or create a new one if necessary.
   • Fork the repository, create a new branch, make changes, test thoroughly, and submit a pull request referencing the related issue.

2. Code Style:

   • Adhere to the project's coding style and guidelines.
   • Ensure code readability and maintainability, along with necessary documentation.

3. Documentation:

   • Enhance the project's documentation, providing clear and concise explanations as needed.

4. Testing:

   • Include relevant tests for new features or bug fixes and ensure all existing tests pass.

Pull Requests:

• Submit pull requests against the main branch.
• Provide a descriptive title and a clear description of the changes made.
• Mention related issues in the pull request.

Thank you for considering contributing to PLIB!

Code Styling Guide

Module Naming:

• Descriptive, concise, and simple module names in lowercase letters only.
• Each module should have its own section in plib.h.

Example:

/*############################################################################*/
/*                                [PlibModuleName]                                */
/*############################################################################*/

File Naming:

• File names must match the function's definition in plib.h.

Example:

// Functions within the string module should reside in string_append_back.c
char *string_append_back(char *str1, char *str2);

Function Naming:

• Functions should start with the prefix of their module.
• Use only prescribed verbs for function names to maintain consistency and clarity.
• Descriptive argument names are encouraged.

/*
create       : Instantiate and perform memory allocation.
destroy      : Deinstantiate and release memory allocation.
copy         : Place the content of 'src' into 'dst' without memory allocation.
clone        : Generate a duplicate of 'src' without altering the original.
count        : Determine the number of occurrences of something.
compare      : Compare two instances of something.
concat       : Append the content of 'src' after 'dst' without additional memory allocations.
contains     : Return a boolean indicating if something exists within something else.
join         : Create memory and concatenate two elements.
length       : Retrieve the length of something (where length signifies within).
size         : Obtain the size of something (where size signifies the container's size).
ends_with    : Verify if something ends with something else.
starts_with  : Verify if something starts with something else.
index_of     : Retrieve the index of something within another something.
assert       : Return a boolean indicating if something conforms to specified criteria.
slice        : Return a duplicate subset of something.
search       : Look for something within another something.
map          : Apply a function to something consistently.
filter       : Return a filtered duplicate of something.
pad          : Return a padded duplicate of something.
trim         : Remove something from both ends of another something.
random       : Generate a pseudo-random value or object.
reverse      : Reverse the order of elements within something.
strip        : Remove something if it exists.
sort         : Arrange elements within something in a specific order.
split        : Divide something and produce additional entities.
set          : Alter something to become something else.
get          : Retrieve or obtain something.
apply        : Use functions to enact modifications on something.
is           : Provide a boolean evaluation (returns 0 or 1).
to           : Transform something into something else.
insert       : Create a new element and place it within something.
remove       : Eliminate an element from something.
append       : Add something to another something.
push         : Insert an existing element into something.
pop          : Remove an element without destroying it from something.
rotate       : Move something into a shifted version of itself.
*/

General Principles:

• Code simplicity is key.
• DRY (Don't Repeat Yourself) principle is encouraged where applicable.
• Comments are omitted in favor of code readability.
• Variants are welcome when logical (e.g., left/right/front/back, etc.).
• Prioritize readability and usability over performance.

Priority for Contribution:

• 1 -> Enhancing test coverage.
• 2 -> Introducing new features, functions, and data structures.
• 3 -> Ensuring naming consistency and refactoring.
• 4 -> Providing comprehensive documentation.
• 5 -> Enhancing the build system.

---

This revised version aims for clearer sections, concise instructions, and a more structured presentation of guidelines and conventions. Feel free to adjust or expand upon any section to better fit the project's needs!

plib's Issues

Creating a doubly linked list implementation.

Plib should have a doubly linked implementation, that mimics all of the functionalities that the current linked list implementation has

• creation of the module
• creation of the definition in plib.h
• implementation of the code.
• implementation of bonus functions.
• building test to ensure correctness.

adding contains/ends_with/starts_with for split.

I think that those functions are really useful and should be implemented.

• implement 'int string_split_contains(char **strs, char *str).
• implement 'int string_split_starts_with(char **strs, char *str).
• implement 'int string_split_ends_with(char **strs, char *str).
• implement the tests for each functions.

Creating documentation for the library.

I think that the library should have some documentation explaining how each functions works, what it does, how it behaves etc.

Migrating toward a modular architecture

Today I've tried to to refactor the library, and I think one way to improve the ease of use would be to switch from a monolithic architecture to a more modular one. I'm trying to prototype this right now to see how it is.

Refactoring all of the stack methods

Good issue too, although the stack is still new it could use a better logic, some refactoring of the variables, of the arguments all for the sake of improving the clarity and the consistency.

Improving current implementation of the linked list.

The current linked list implementation could use more functionalities, It's the basis of a lot of other data structures and it's very useful for a lot of tasks. Here are a few suggestions of functions that could prove useful.

• Function to clear the list (setting all of the void *data to zero without freeing the list, like the stack_clear function)
• Function to see if a list contains something (int list_contains(t_list **self, void *search, int (*f)(void *a, void *b))
• Function to see if a list starts_with something (int list_starts_with(t_list **self, void *search, int (*f)(void *a, void *b))
• Function to see if a list ends_with something (int list_ends_with(t_list **self, void *search, int (*f)(void *a, void *b))
• Function to search the first occurrence of something (t_list *list_find_first(t_list **self, void *search, int (*f)(void *a, void *b))
• Function to search the last occurrence of something (t_list *list_find_last(t_list **self, void *search, int (*f)(void *a, void *b))
• Function to replace one occurrence of something (t_list * list_replace(t_list **self, void *search, int (*f)(void *a, void *b))
• Function to replace all occurrence of something (t_list * list_replace(t_list **self, void *search, int (*f)(void *a, void *b))

This is just a beginning in reality a lot more could be added to the list.

General Refactoring

This is more of a long term goal, I really want that library to be consistent, in the naming convention, and in the behaviour. The thing is that it's quite hard to be consistent across 10 thousand lines of code. So everytime you see an inconsistence somewhere please mention it here so I can look into that.

I'm also open to any suggestion regarding the general improvement of the naming convention etc.

Implementing robust file handling

PLIB should provide a consistent and easy to use API wrapping the 42's authorised functions like open/read/ etc.

• implement a coherent file defintion
• implement a robust set of file functions
• implement high level manipulation of files
  Bonus
• implement a tree structure to handle directories and fuzzy searching maybe ?

Improve test coverage for string functions.

For the module string, I think that some functions could use a bit more testing, in order to ensure correctness.

1 - all functions should have a test for null variant.
2 - all functions should have a test for edge cases (like size 0, or end of something etc.)
3 - all functions should have a normal use case test.

Refactoring of all the string methods

This will be a long and tiresome job, but it needs to be done, and I think it's a good way to start, the current code is not really good and consistent. The naming of the variables is all over the place and it could be better. The idea is to real the code and think of what each parts means find some patterns and try to rename inconsistent variables, improve the logic of the code and it's robustness, I think some functions could use more safety and checks for NULL when it make sense etc.

Discussion about future features for the library

So since we are now sharing the development of PLIB, we need to discuss about what we want it to be, what are the features we would like to see, and what we need. This will be a long issue because it will take us some times to figures out what is truly missing from this library.

I know that we are still discovering C, and there is still a lot to learn and so it can be hard to know what we need. But really I would really appreciate if everyone could spend some times using the library to solve a few problems on leetcode, or something like that, maybe we could also start a small project like a cli tool and see how usefull PLIB is and what is truly missing from it.

One idea that I had would be to take maybe a week-end or something and sort of do a "hackaton" where we try to use the library to quickly put together a tool or something just so that we can quickly get insight and experience of where is the library missing something, what functions are not useful etc.

I'm not sure yet how to do all of that but I think this could be great for all of us, both as a way to get more familiar with the library and to also get started on how to improve it.

List_create not very ergonomic in certain situations

Today I was trying to implement a method that takes the content of a file and splits it into node of a linked list. The problem is that the methods list_create, will initiate the void* data and when inserting back the different chunk of the split, it will do it like you would expect, which mean that it's not really practical to instantiate a data structure object with it's content, I think it needs to be separated.

The problem is that a ton of code depends on that behaviour and this will break a lot of thing especially the test cases.

Refactoring of the plib.h file

The way I see it plib.h is great because it includes everything, when you need to look at the definition of something it's in there. But it's a bit of a mess, I think it would be worth it to send sometimes refactoring it to improve the style, the spacing, the headers for each sections etc, making the code look nice.

Creation of a stack data structure

PLIB need to have a robust stack data structure for the purpose of the project push swap, as such the stack data structure should not only implement the basic behaviour of a stack but also the different functions that will be required by push swap.

• implementing the stack definiton
• implementing the basic of the stack
• implementing the push swap additional functions
• writing extensive test coverage.

Implementation of an argument parsing module

Loads of programs we are going to create in 42, will need some form of argument parsing as a basis, this is often just string manipulation and with the strings functions being so complete I think this is going to be easy.

• Implement an argument parsing structure / definition
• implement a prototype of working functions
• implementing a few tests

Implementing a tree data structure.

Plib should provide a simple and easy to use tree data structure

• creation of the module
• creation of the definition in plib.h
• implementation of the code.
• implementation of bonus functions.
• building test to ensure correctness.

Improvement of the build system

Today's experiment at 42 revealed that the makefile is flaky and the compilation process is not perfect, It needs to be seamless.

• refactor the makefiles.
• ensure compilation works on 42's sessions.

Of course I'm open to any suggestions when it comes to fixing this issue.